x86 & x64

[Davi]

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)?.

 

[kassane]

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.

[fredericopissarra]

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...

[fredericopissarra]

Ahhh... alguns sistemas operacionais abandonaram de vez o modo i386 e a tendência é que esse modo desapareça, com o tempo...

[fredericopissarra]

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.

[fredericopissarra]

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.

[Davi]

Obrigado pelas respostas.

E a arquitetura ARM, muda alguma coisa?

[kassane]

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

[fredericopissarra]

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).

[kassane]

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)

[fredericopissarra]

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).