Jump to content
Sign in to follow this  
Davi

x86 & x64

Recommended Posts

Qual é mais "Seguro"? x86 ou x64?

Por que a maioria dos unpackers, debuggers e ferramentas são para x86.

Existe alguma diferença entre x86 e x64? (em questão do assembly)?.

 

Share this post


Link to post
Share on other sites

Olá @Davi, blz?

Não tem nada ver com segurança, mas em mudança de arquitetura. X86, x86_64, Intel 64

A maioria das ferramentas em si são 32 bits popularmente devido a alta dependência de sistemas obsoletos que ainda existem. Por exemplo, uma empresa que entrega encomendas (como correios) usa Win7 x86 pois acreditam que seja mais estável e barato para o suporte.

  • Curtir 3

Share this post


Link to post
Share on other sites

Costumo chamar os modos de operação de processadores Intel e AMD de i386 e x86-64, mas na nomenclatura da Intel são, respectivamente, IA-32 e IA-32e. Ambos são "modos", existentes no mesmo processador. Portanto, não tem muito sentido falar em "segurança".

A "maioria" das ferramentas citadas não são para i386, não hoje em dia...

Existem diversas diferenças nos modos de operação. A primeira, e mais evidente, é que no x86-64 você pode lidar com registradores de 64 bits; Os ponteiros (endereços) passam a ter 64 bits de tamanho (embora apenas 48 sejam usados para endereçamento linear).

Algumas outras vantagens do x86-64 sobre o i386, algumas com relação às calling conventions na MS ABI e no SysV ABI, são:

  • Os seletores de segmento não são usados, exceto pelos atributos (apenas alguns) de CS e os endereços base dos descritores quando FS e GS são usados... Todos os outros são ignorados; Isso significa que a memória é flat;
     
  • Como consequência da memória flat, todo o esquema de proteção é feito pelos diretórios de página. O modo paginado não é uma opção no modo x86-64. É obrigatório. E também existe uma extensão... No modo x86-64 podemos criar páginas de 4 KiB, 2 MiB ou 1 GiB. Páginas de 1 GiB não são possíveis no modo i386 (nem com PAE e PSE habilitados!);
     
  • O conjunto de registradores de uso geral é aumentado em 8 registradores extras. Temos RAX, RBX, RCX, RDX, RSI, RDI, RBP, RSP, como extensões de 64 bits para os equivalentes EAX, EBX, ECX, EDX, ESI, EDI, EBP e ESP; mas também temos R8, R9, R10, R11, R12, R13, R14 e R15. Com mais registradores não precisamos fazer uso da pilha para passar argumentos para funções... No Linux, por exemplo, os registradores RDI, RSI, RDX, R8 e R9 são usados para passar os 5 primeiros argumentos para qualquer função (se houverem mais argumentos a pilha é usada) -- No caso do Windows x64, a M$ preferiu usar apenas 4 e a ordem é RCX, RDX, R8 e R9;
     
  • O modo x86-64 continua sendo de 32 bits, mas com extensão para 64. Assim, instruções como  MOV EAX,0 continuem usando a mesmíssima instrução do modo i386... Isso não significa compatibilidate total, já que algumas instruções, no modo x86-64, não existem mais, como AAA, AAM, DAA. Outro detalhe é que ao manipular os registradores de 32 bits (EAX, EBX, ...), automaticamente os 32 bits superiores são zerados. O MOV EAX,0, por exemplo, faz a mesma coisa que MOV RAX,0, mas usa uma instrução menor.
     
  • Com mais registradores sobrando, o modo x86 permite alocação mais variaveis locais em registradores, ao invés da pilha. Os registradores RBX e RBP continuam tendo que ser preservados, entre chamadas, como no modo i386, na maioria dos calling conventions. No Linux isso também é verdade de R12 até R15. No Windows, RDI e RSI também entram nessa lista.

    Todos os demais, exceto, é claro, RIP e RSP, podem ser usados à vontade...
     
  • Em todos os processadores que suportam o modo x86-64 está disponível SSE. Assim, o modelo de ponto flutuante preferido dos compiladores é o SSE. Isso significa que os registradores XMM0 até XMM7 são usados para passar os argumentos de tipos como float e double (long double não!). E, já que o modo x86-64 também estende a quantidade de registradores SSE, XMM8 até XMM15 estão disponíveis (i386, quando implementa SSE, só tem os 8 primeiros)... No caso da Microsoft, apenas XMM0 até XMM3 são usados como argumentos de funções.

Sugiro, fortemente, que abandonem o modo i386 nos processadores Intel, a não ser para sistemas que dependam de hardware com processador anterior ao Pentium 4 (anteriores a novembro de 2000). Há quase 20 anos o modo x86-64 está disponível e ele permite a criação de código "menor" (em termos de instruções) e mais performático...

  • Curtir 2

Share this post


Link to post
Share on other sites
Posted (edited)

Ahhh, sim... Para acessar as porções de 32, 16 ou 8 bits inferiores dos registradores "extras", no modo x86-64, basta usar um sufixo. Exemplo: R8D é o DWORD (32 bits) inferior de R8... Temos R8W e R8L ( como em AL, para RAX ) também. Isso vale para todos os outros, de R8 até R15.

O modo x86-64 ganhou os pseudo-registradores de 8 bits para RSI, RDI, RBP e RSP também: SIL, DIL, BPL e SPL (mas não existem as versões 'H').

Nada disso está disponível no modo i386.

Edited by fredericopissarra
  • Curtir 1

Share this post


Link to post
Share on other sites

MAIS uma coisa disponível no modo x86-64 que não existe no modo i386. No cálculo de endereços efetivos, pode-se usar o registrador RIP como base, ou seja, o endereço pode ser relativo ao RIP (assim como os saltos o são!)... Isso facilita a criação de código indepependente de posição e diminui, consideravelmente, a tabela de relocação nas imagens binárias de executáveis e bibliotecas dinâmicas...

O endereçamento de dados relativo não existe no modo i386.

  • Curtir 1

Share this post


Link to post
Share on other sites

Obrigado pelas respostas.

E a arquitetura ARM, muda alguma coisa?

Share this post


Link to post
Share on other sites

ARM é  uma arquitetura totalmente diferente e parametrizável, que tem como principal objetivo o baixo consumo.

  • Curtir 1

Share this post


Link to post
Share on other sites
1 hora atrás, kassane disse:

ARM é  uma arquitetura totalmente diferente e parametrizável, que tem como principal objetivo o baixo consumo.

O objetivo não é, necessariamente, o "baixo consumo" (modelos Atom dos processadores Intel têm esse objetivo tb!). Não entendi o que significa "parametrizável", nesse contexto...
Mas, de fato, ARM é completamente diferente (RISC).

  • Curtir 1

Share this post


Link to post
Share on other sites
Posted (edited)
36 minutos atrás, fredericopissarra disse:

Não entendi o que significa "parametrizável", nesse contexto...

 

Parametrizável, no sentido de prioridade/objetivo em relação ao consumo de energia. Já que ARM pode desativar núcleos quando está com pouca carga de trabalho.

 

Acredito que anteriormente acabei descrevendo de forma ambígua a objetividade. (IMHO)

Edited by kassane
Justificação

Share this post


Link to post
Share on other sites
5 horas atrás, kassane disse:

Parametrizável, no sentido de prioridade/objetivo em relação ao consumo de energia. Já que ARM pode desativar núcleos quando está com pouca carga de trabalho.

Hummm... Isso também existe nos processadores não-ARM, incluindo x86...

A vantagem do RISC é apenas a pequena quantidade de instruções e, em teoria, um circuito mais "enxuto". Nesse aspecto eu posso concordar com o menor "consumo de energia", mas esse é um efeito colateral, não o "objetivo" do bicho... O objetivo é a simplicidade, ao meu ver...

Acredito que o problema de packages como os da Intel/AMD tornaram-se muito complexos (no sentido de terem muitos recursos que, na maioria das implementações, são supérfluas).

  • Curtir 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...