Este artigo não cita fontes confiáveis. Ajude a inserir referências. Conteúdo não verificável pode ser removido.—Encontre fontes: ABW  • CAPES  • Google (N • L • A) (Março de 2019)

O bit NX, que deriva da expressão em inglês No eXecute, é uma tecnologia usada em alguns processadores e sistemas operacionais que separa de modo rígido as áreas de memória que podem ser usadas para execução de código daquelas que só podem servir para armazenar dados. Ele é usada com propósitos de segurança.

Uma área da memória que esteja marcada com o atributo NX pode ser usada somente para guardar dados, então quaisquer instruções que estejam nela não serão executadas. A técnica serve para prevenir certos tipos de ataques feitos por malwares, quando o programa malicioso insere instruções na área de dados de outro programa, tentando que elas sejam executadas a partir de lá. Esse tipo de ataque é chamado de buffer overflow.

O termo "bit NX" foi criado e é usado comercialmente pela AMD. No entanto, tecnologia idêntica foi implementada pela Intel, com o nome bit XD, que deriva da expressão em inglês eXecute Disable. Ambas as tecnologias funcionam do mesmo modo e se diferenciam apenas pelo nome.

Vários sistemas operacionais dão suporte ao bit NX. Entre eles, o Windows XP (a partir do Service Pack 2), o Linux (a partir do núcleo 2.6.8) e o Mac OS X (em todas as versões para processadores Intel).

Processadores X86, a partir do 80286, incluíram uma capacidade similar implementada no nível de segmento. Porém, atuais sistemas operacionais implementando o modelo de memória plana não podem usar esta capacidade. Não havia um flag “executável” na página de entrada de tabela no 80386 e nos processadores x86 lançados mais tarde, até que, para fazer esta capacidade disponível para sistemas operacionais que usavam o modelo de memória plana, AMD adicionou um “bit não executável (do inglês not executable bit)” ou bit NX à página de entrada de tabela em sua arquitetura amd64 fornecendo um mecanismo que pode controlar execuções por página ao invés do segmento inteiro. O mecanismo em nível de página esteve disponível por anos em várias outras arquiteturas de processadores, como DEC(agora HP), Alpha, Sun’s SPARC e os Sistema/370-XA, sistema/390, z/Architeture e PowerPC da IBM. A Intel implementou uma característica similar em seu processador Itanium(tendo arquitetura IA-64) em 2001, mas não o implementou nas famílias de processadores x86 mais populares. Na arquitetura x86, foi implementado pela AMD, como bit NX, para uso em sua linha de processadores AMD64, como o Athlon 64 e Opteron. O termo bit NX se tornou utilizado para descrever tecnologias similares em outros processadores. Após a decisão da AMD de incluir esta funcionalidade no conjunto de instrução de seu AMD64, a Intel implementou uma característica similar em seus processadores x86, começando com o Pentium 4 baseado em iterações posteriores do núcleo Prescott. Bit NX se refere especificamente ao bit de número 63(o mais significante bit) de uma entrada de 64 bits em uma página de tabela. Se este bit tem o valor 0, então o código pode ser executado daquela página, se tem valor 1, o código não pode ser executado daquela página, e qualquer outra coisa residindo ali é assumido como sendo dados.

Antes do início desse recurso dentro do hardware, sistemas operacionais diversos tentaram emular esse recurso através de software, tais como W ^ X ou Exec Shield. Um sistema operacional com a capacidade de emular e / ou tirar proveito de um bit NX pode impedir que áreas de memória em pilha sejam executáveis, e pode impedir memória executável de ser gravável. Isso ajuda a evitar o sucesso de explorações de determinados overflows de buffer, particularmente aqueles que injetam e executam códigos, como os worms Sasser e Blaster. Esses ataques dependem de alguma parte da memória, geralmente a pilha, para ser tanto gravável e executável, se ele não for, o ataque falha.

O kernel do Linux atualmente utiliza o bit nx em CPUs x86-64 e em processadores x86 que o suportam, assim como os atuais x64 da AMD, Intel, Transmeta e VIA. O suporte para este recurso no modo de 64 bits em CPUs x86-64 foi adicionado em 2004 por Andi Kleen, e mais tarde no mesmo ano, Ingo Molnar adicionou suporte para ele no modo de 32 bits em CPUs de 64 bits. Esses recursos têm estado no kernel do Linux desde a versão 2.6.8 em agosto de 2004. A disponibilidade do bit nx em kernels 32-bit x86, que pode rodar em ambas CPUs 32 bit x86 e CPUs 64 bit x86 compatíveis, é significante porque um kernel 32 bit x86 normalmente não espera o bit NX que um AMD64 ou IA-64 fornece, o patch que ativa o NX assegura que estes kernels irão tentar utilizar o bit NX, se presente. Algumas distribuições de desktop do Linux, como Fedora Core 6, Ubuntu e openSUSE, não permitem a opção HIGHMEM64 por padrão, o que é necessário para ter acesso ao bit NX em modo 32 bit. Isto acontece porque o modo PAE que é requerido para usar o bit NX faz com que processadores sem suporte NX falhem em fazer boot. Proteção de memória NX sempre esteve disponível no Ubuntu para qualquer sistema que tivesse o hardware que suportasse e rodasse o kernel 64-bit e o kernel do servidor 32-bit. A funcionalidade NX também está presente em outros processadores não x86 Ingo Molnar, desenvolvedor do kernel Red Hat liberou, em 2003, um patch para o kernel do Linux chamado Exec Shield, para utilizar a funcionalidade NX em CPUs 32-bit x86. Foi rejeitado para se misturar com o kernel do linux pois para poder lidar com as complexas partes de truques de emulação, envolvia algumas mudanças importunas aos códigos mais importantes do kernel.

A tecnologia PaX NX pode emular o bit NX ou a funcionalidade NX, ou usar um bit NX do hardware. PaX funciona em CPUs x86 que não tem o bit NX. Enquanto disponibilizava uma implementação da funcionalidade NX muito mais completa do que seu competidor mais próximo Exec Shield, é uma modificação do kernel do Linux muito mais invasiva e pode estar inclinada a quebrar aplicações.

Microsoft Windows usa por padrão proteção NX exclusivamente em serviços Windows críticos. No Windows XP e Server 2003, o recurso é chamado Prevenção de Execução de Dados(DEP, do inglês Data Execution Prevention), e pode ser configurado através da tabela avançado nas propriedades de sistema. Se um processador x86 tem suporte a esse recurso no hardware, então o recurso NX é por padrão ativado automaticamente nos Windows XP/Server 2003. Se o recurso não é suportado pelo processador x86, a proteção não é ativada. DEP por software não é relacionada ao bit NX, é o que a Microsoft chama de Proteção Estruturada de Manuseio de Exceção. DEP por software checa quando uma exceção é feita para ter certeza que a exceção está registrada em uma tabela de funções para a aplicação. Implementações iniciais da DEP não disponibilizavam espaço de endereço de disposição aleatória (address space layout randomization, ASLR), que permitiam ataques. A documentação PaX elaborou o porquê o ASLR é necessário, uma prova do conceito foi elaborada detalhando um método pelo qual o DEP poderia ser contornado na ausência do ASLR. Pode ser possível desenvolver um ataque de sucesso se o endereço de dados preparados como imagens corrompidas ou arquivos MP3 são conhecidos pela pessoa que realiza o ataque. A Microsoft adicionou ASLR no Windows Vista e Windows Server 2008 para proteger contra esse tipo de ataque.

Características das tecnologias NX serão comparadas e contrastadas. Geralmente, NX bit emulação está disponível apenas em CPUs x86. As seções dentro de lidar com emulação estão preocupados apenas com CPUs x86 salvo indicação em contrário. Embora tenha sido provado que alguns métodos de emulação de NX bit geram um overhead extremamente baixo, também foi comprovado que tais métodos podem tornar-se imprecisos. Por outro lado, outros métodos podem ter um overhead extremamente alto e ser absolutamente precisos. Nenhum método foi descoberto até o momento sem uma significativa “trade-off” , seja no poder de processamento, precisão, ou o espaço de memória virtual. Overhead : Sobrecarga, quantidade de energia extra de processamento da CPU que é necessário para cada tecnologia funcionar. Todas as tecnologias criam uma sobrecarga devido à lógica de programação extra que deve ser criada para controlar o estado do bit NX para várias áreas de memória, no entanto, a avaliação é normalmente tratado pelo CPU. Em CPUs fornecendo um hardware bit NX, nenhuma das tecnologias listadas impõe qualquer sobrecarga significativa mensurável, a menos que seja indicado. PaX fornece dois métodos de emulação de NX bit, chamado SEGMEXEC e PAGEEXEC. O método SEGMEXEC impõe uma sobrecarga mensurável, mas baixa, normalmente menos de 1%. Este é um escalar constante devido ao espelhamento de memória virtual usada. Também tem o efeito de reduzir pela metade o espaço da tarefa de endereço virtual, permitindo que a tarefa acesse menos memória do que normalmente faria. Este não é um problema até que a tarefa necessite de acesso a mais de metade do espaço de endereços do normal, o que é raro. SEGMEXEC não tem programas para usar mais memória do sistema (RAM), mas apenas restringe o quanto eles podem acessar. Em CPUs de32-bit , seria 1,5 GB ao invés de 3 GB. No PAGEEXEC, é fornecido um método semelhante a Exec Shield , com um aumento de velocidade, mas quanto mais memória está marcada como executável, o método perde sua proteção. Nestes casos, PaX cai de volta para o método mais antigo, com variáveis utilizadas por PAGEEXEC para proteger páginas abaixo do limite de CS, que pode tornar-se uma operação de sobrecarga bastante elevada em certos padrões de acesso de memória.

Exec Shield: Para CPUs sem um bit NX, Exec Shield não protege páginas abaixo do limite de segmento de código; faz-se uma mprotect () para marcar mais memória. Assim, nessas situações, esquemas de Exec Shield falham. PAX: SEGMEXEC não depende de tais sistemas voláteis que são utilizados nos Exec Shield, e, portanto, não encontra condições em que a emulação bit NX finamente granulado não pode ser imposta, mas no entanto, têm a redução para metade do espaço de endereço virtual. PAGEEXEC vai cair de volta para o método PAGEEXEC original usado antes. Em ambos os casos, a emulação PaX "permanece 100% exato e será executável . É interessante notar que suprimentos mprotect () são restrições para impedir que programas de marcação de memória utilizem a memória útil para uma exploração em potencial.

Algumas tecnologias permitem que os programas executáveis de marcação relaxem as restrições impostas pela tecnologia NX para tal programa específico. Vários sistemas oferecem vários controles. Exec Shield fornece marcas executáveis e somente verifica a existência de duas marcações de cabeçalho, que ditam se a pilha precisa ser executável. São chamados PT_GNU_STACK e PT_GNU_HEAP, respectivamente. Exec Shield permite que estes controles sejam definidos para ambos os binários executáveis e bibliotecas. Se uma execução carrega uma biblioteca que requer uma restrição dada, essa execução irá herdar essa marcação e tem essa restrição. PaX tem suprimentos de controle refinados sobre as proteções. Permite o controle individual sobre as seguintes funções da tecnologia para cada binário executável: Espaço de proteções executáveis; PAGEEXEC; SEGMEXEC; Restrições mprotect (); Emulação de trampolim; Base de execução randomizada; Randomização mmap () base; PaX ignora completamente PT_GNU_STACK e PT_GNU_HEAP. Houve um momento em que PaX tinha uma opção de configuração para honrar essas configurações, mas foi removida por razões de segurança, uma vez que não foi considerada útil. Os mesmos resultados de PT_GNU_STACK podem normalmente ser alcançados pela desativação de restrições mprotect. Isto pode não ser sempre válido, porque as situações onde isso não funciona desabilitando PAGEEXEC e SEGMEXEC irão efetivamente remover todas as restrições de espaço executável, dando a tarefa a mesma proteção em seu espaço executável como um sistema não-PaX.

Este artigo sobre computação é um esboço. Você pode ajudar a Wikipédia expandindo-o. v d e