Davi Posted March 17, 2019 at 01:28 PM Share Posted March 17, 2019 at 01:28 PM 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)?. Link to comment Share on other sites More sharing options...
kassane Posted March 17, 2019 at 02:12 PM Share Posted March 17, 2019 at 02:12 PM 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. Link to comment Share on other sites More sharing options...
fredericopissarra Posted March 17, 2019 at 02:31 PM Share Posted March 17, 2019 at 02:31 PM 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... Link to comment Share on other sites More sharing options...
fredericopissarra Posted March 17, 2019 at 02:34 PM Share Posted March 17, 2019 at 02:34 PM Ahhh... alguns sistemas operacionais abandonaram de vez o modo i386 e a tendência é que esse modo desapareça, com o tempo... Link to comment Share on other sites More sharing options...
fredericopissarra Posted March 17, 2019 at 03:21 PM Share Posted March 17, 2019 at 03:21 PM 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. Link to comment Share on other sites More sharing options...
fredericopissarra Posted March 17, 2019 at 03:26 PM Share Posted March 17, 2019 at 03:26 PM 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. Link to comment Share on other sites More sharing options...
Davi Posted March 18, 2019 at 11:44 AM Author Share Posted March 18, 2019 at 11:44 AM Obrigado pelas respostas. E a arquitetura ARM, muda alguma coisa? Link to comment Share on other sites More sharing options...
kassane Posted March 18, 2019 at 12:17 PM Share Posted March 18, 2019 at 12:17 PM ARM é uma arquitetura totalmente diferente e parametrizável, que tem como principal objetivo o baixo consumo. Link to comment Share on other sites More sharing options...
fredericopissarra Posted March 18, 2019 at 01:19 PM Share Posted March 18, 2019 at 01:19 PM 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). Link to comment Share on other sites More sharing options...
kassane Posted March 18, 2019 at 01:55 PM Share Posted March 18, 2019 at 01:55 PM 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) Link to comment Share on other sites More sharing options...
fredericopissarra Posted March 18, 2019 at 07:19 PM Share Posted March 18, 2019 at 07:19 PM 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). Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.