O que quer que seu firmware tenha deixado.
Em um sistema moderno ideal, o processador nunca entra em modo real, como expliquei neste documento.
Como os modernos PCs com chip Intel de 64 bits executam o setor de inicialização? , o primeiro KiB da memória física é tão irrelevante quanto Johan Myréen chegou a ser em outra resposta aqui. Mas muitos firmwares modernos (ainda) têm suporte a compatibilidade , o que significa que- eles podem retroceder (sim, voltar , dado que foram diretamente do modo irreal para o modo protegido) do modo protegido para o modo real para executar softwares do sistema que são escritos em modo real, tais como programas de inicialização do estilo antigo PC / AT em MBRs e VBRs; e
- eles fornecem as APIs de firmware do modo real antigo e configuram todas as estruturas de dados para essas APIs, das quais os softwares de sistemas mencionados anteriormente dependem.
Uma dessas estruturas de dados é o modo real IVT. As antigas APIs de firmware de modo real são baseadas em instruções int , e o IVT de modo real é preenchido pelo firmware como parte de sua inicialização com ponteiros para as diversas rotinas de manipulação de firmware para essas instruções.
Os softwares de sistema no modo protegido não precisam das APIs de firmware do modo real antigo e nunca executam o processador em modo real, portanto, o modo real IVT no primeiro 1 KiB de memória física não é utilizado. (o modo protegido v8086 não endereça o endereço físico 00000000 e para cima, lembre-se. Endereços lógicos 00000000 e para cima, que são traduzidos por tabelas de páginas.) Em sistemas EFI modernos, o firmware entrega um mapa de memória da memória física ao bootstrap do sistema operacional, informando quais partes estão reservadas ao firmware para suas próprias finalidades de API de modo protegido e quais partes do sistema operacional é livre para ir em frente e usar para seu pool de memória física. Em teoria, a primeira página da memória física pode estar na última categoria.
Na prática, primeiramente, os firmwares geralmente marcam a primeira página da memória física como "boot services code", significando que um sistema operacional pode reivindicá-lo e simplesmente usá-lo como parte de seu sistema operacional. pool de memória física, mas somente após os serviços de tempo de inicialização do firmware EFI foram encerrados pelo sistema operacional e o firmware foi reduzido para fornecer apenas seus serviços de tempo de execução. Um exemplo disso pode ser visto no log do kernel do Linux (com a opção add_efi_memmap ) mostrado por Finnbarr P. Murphy:
[ 0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)que xe decodifica com outro programa em uma forma mais legível como:
[#00] Type: EfiBootServicesCode Attr: 0xF
Phys: 0000000000000000-0000000000001000
Virt: 0000000000000000-0000000000001000
Na prática, em segundo lugar, o Linux explicitamente ignora esse intervalo de memória física mesmo que o firmware diga que ele pode ser usado e usado. Você descobrirá isso tanto nos firmwares EFI quanto nos não-EFI, assim que o Linux tiver o mapa de memória física, ele corrige (em uma função chamada trim_bios_range ), resultando em mensagens de log do kernel como:
[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Isto não é tanto para lidar com firmwares EFI modernos, onde o modo real IVT não faz parte da API de firmware, como é lidar com firmwares PC98 antigos, onde é parte da API de firmware, mas o relatório firmwares (através da mesma API) como memória física disponível para ser reescrita pelo sistema operacional.
Assim, enquanto que, teoricamente, a faixa de memória física poderia conter código ou dados arbitrários, dependendo das necessidades momentâneas dos alocadores de memória do kernel e da memória virtual paginada por demanda; na prática, o Linux simplesmente o deixa intacto, já que o firmware originalmente o configurou.E no seu sistema, o firmware o preenchia com entradas IVT de modo real. Entradas de IVT em modo real são apenas 16:16 ponteiros distantes, é claro, e se você olhar para sua memória usando um hexdump de 2 bytes, você pode realmente ver isso claramente. Alguns exemplos:
- A maioria de suas entradas de IVT apontam para F000: FF53, um endereço na área ROM de firmware de modo real. É provavelmente uma rotina fictícia que não faz nada mais do que um
iret. - A entrada 1E do IVT aponta para F000: 6AA4, uma tabela na mesma área da ROM.
- Entrada IVT 1F aponta para C000: 8930, uma tabela na área de firmware da ROM de vídeo em modo real.
- A entrada IVT 43 aponta para C000: 6730, outra tabela na área de firmware da ROM de vídeo em modo real.
Leitura adicional
- Finnbarr P. Murphy (2012-08-18). Memória UEFI V E820 Memória . fpmurphy.com.
- Em que modo os modernos PCs com chip Intel de 64 bits executam o setor de inicialização?
