What does physical address 0 in x86 Linux contain?

Whatever your firmware left it containing.

On an ideal modern system, the processor never enters real mode at all, as I explained in this SU Q&A titled: What mode do modern 64-bit Intel chip PCs run the boot sector in?, the first KiB of physical memory is as irrelevant as Johan Myréen made it out to be in another answer here. But many modern firmwares (still) have compatibility support, meaning that

  • they can drop back (yes, back, given that they went directly from unreal mode to protected mode) from protected mode to real mode in order to run system softwares that are written for real mode, such as old style PC/AT boot programs in MBRs and VBRs; and
  • they provide the old real mode firmware APIs and set up all of the data structures for those APIs, that the aforementioned system softwares rely upon.

One of those data structures is the real mode IVT. The old real mode firmware APIs are based upon int instructions, and the real mode IVT is populated by the firmware as part of its initialization with pointers to the various firmware handling routines for those instructions.

Protected mode system softwares do not need the old real mode firmware APIs, and never run the processor in real mode, so the real mode IVT in the first 1KiB of physical memory is unused. (v8086 protected mode does not address physical address 00000000 and upwards, remember. It addresses logical addresses 00000000 and upwards, which are translated by page tables.) In modern EFI systems, the firmware hands over a memory map of physical memory to the operating system bootstrap, telling it which parts are reserved to the firmware for its own protected mode API purposes, and which parts the operating system is free to just go ahead and use for its pool of physical memory. In theory, the first page of physical memory can be in the latter category.

In practice, firstly, firmwares often mark the first page of physical memory as "boot services code", meaning that an operating system can claim it and just go ahead and use it as part of its physical memory pool, but only after the boot-time services of the EFI firmware have been shut down by the operating system and the firmware reduced to providing its run-time services only. An example of this can be seen in the Linux kernel log (with the add_efi_memmap option) shown by Finnbarr P. Murphy:

[ 0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)
which xe decodes with another program in a more human-readable form as:

[#00] Type: EfiBootServicesCode Attr: 0xF
      Phys: 0000000000000000-0000000000001000
      Virt: 0000000000000000-0000000000001000

In practice, secondly, Linux explicitly ignores this range of physical memory even if the firmware says that it can go ahead and use it. You'll find that on both EFI and non-EFI firmwares alike, once Linux has the physical memory map it patches it (in a function named trim_bios_range), resulting in kernel log messages such as:

[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

This is not so much to cope with modern EFI firmwares, where the real mode IVT is not part of the firmware API, as it is to cope with old PC98 firmwares, where it is part of the firmware API but the firmwares report it (via that self-same API) as physical memory available to be blithely overwritten by the operating system.

So whilst in theory that range of physical memory could contain arbitrary code or data, depending from the momentary needs of the kernel memory allocators and demand-paged virtual memory; in practice Linux just leaves it untouched as the firmware originally set it up.

And on your system the firmware had populated it with real mode IVT entries. Real mode IVT entries are just 16:16 far pointers, of course, and if you look at your memory using a 2-byte hexdump you can actually see this pretty clearly. Some examples:

  • Most of your IVT entries point to F000:FF53, an address in the real mode firmware ROM area. It is probably a dummy routine that does nothing more than an iret.
  • IVT entry 1E points to F000:6AA4, a table in that same ROM area.
  • IVT entry 1F points to C000:8930, a table in the real mode video ROM firmware area.
  • IVT entry 43 points to C000:6730, another table in the real mode video ROM firmware area.

Further reading

  • Finnbarr P. Murphy (2012-08-18). UEFI Memory V E820 Memory. fpmurphy.com.
  • What mode do modern 64-bit Intel chip PCs run the boot sector in?

The original 8086 processor architecture (implemented as Real Mode in 80286+ processors) has no relevance for Linux, which operates in Protected Mode. There is no interrupt vector table at physical address 0, instead an Interrupt Descriptor Table containing Interrupt Descriptors is used. The IDT can be located anywhere in memory.

The Linux kernel gets a physical memory map from the firmware (BIOS or EFI) which tells which physical memory page frames are usable and which are reserved or not present. The range of usable page frames is not contiguous, but typically has huge holes in it. Traditionally, the x86 Linux kernel has skipped the start of physical memory, even if it is marked as usable. Thus, physical address 0 is not used by the Linux kernel.


Dumping memory

Here's an alternative way to dump the contents of memory inside the system vs. having to do it externally:

$ head /dev/mem | hexdump -C
00000000  53 ff 00 f0 53 ff 00 f0  53 ff 00 f0 53 ff 00 f0  |S...S...S...S...|
00000010  53 ff 00 f0 53 ff 00 f0  cc e9 00 f0 53 ff 00 f0  |S...S.......S...|
00000020  a5 fe 00 f0 87 e9 00 f0  53 ff 00 f0 46 e7 00 f0  |........S...F...|
00000030  46 e7 00 f0 46 e7 00 f0  57 ef 00 f0 53 ff 00 f0  |F...F...W...S...|
00000040  22 00 00 c0 4d f8 00 f0  41 f8 00 f0 fe e3 00 f0  |"...M...A.......|
00000050  39 e7 00 f0 59 f8 00 f0  2e e8 00 f0 d4 ef 00 f0  |9...Y...........|
00000060  a4 f0 00 f0 f2 e6 00 f0  6e fe 00 f0 53 ff 00 f0  |........n...S...|
00000070  ed ef 00 f0 53 ff 00 f0  c7 ef 00 f0 ed 57 00 c0  |....S........W..|
00000080  53 ff 00 f0 53 ff 00 f0  53 ff 00 f0 53 ff 00 f0  |S...S...S...S...|
...
...
000afea0  00 00 00 00 00 00 00 00  aa aa aa 00 aa aa aa 00  |................|
000afeb0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000b0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000c0000  55 aa 40 e9 62 0a 00 00  00 00 00 00 00 00 00 00  |[email protected]...........|
000c0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 49 42  |..............IB|

Analysis

The upper portion above 000c0000 could be bootloader related. Why would I suspect this? The code 55aah at location 000c0000 can typically be a mark in memory for things such as a trigger for the BIOS to run a secondary bootloader.

Reference: Boot Signature - BIOS

  ss#1

However, given this 55aah occurs in the c0000h-effffh range it's more likely this portion is the PNP Expansion Header:

Reference: BIOS Boot Specification

3.3 Devices with PnP Expansion Headers

All IPL devices with option ROMs must contain a valid option ROM header that resides between system memory addresses C0000h and EFFFFh on a 2k boundary and begins with 55AAh. A Device’s booting can only be controlled if it has a PnP Expansion Header. The Expansion Header, whose address resides within the standard option ROM header at offset +1Ah, contains important information used to configure the device. It also contains pointers to code in the device’s option ROM (BCV or BEV) that the BIOS will call to boot from the device. See Appendix A for the structure of the PnP Expansion Header. There are two ways an IPL device with a PnP Expansion Header can be booted. It must contain a BCV or a BEV.

53ff...

As to the 53ffh data that is at the beginning. It's unclear to me what that actually is. Further researching it it's likely something that the Linux kernel wrote there after the BIOS' bootloading of the MBR handed off to the Linux kernel to boot.

Usually, the bootloader will load the kernel into memory, and then jump to the kernel. The kernel will then be able to reclaim the memory used by the bootloader (because it has already performed its job). However it is possible to include OS code within the boot sector and keep it resident after the OS begins

Digging further I was able to find this paragraph from a research paper titled: Malicious Code Injection via /dev/mem:

1 The mem Device

/dev/mem is the driver interface to physically addressable memory. The original intent of both mem and kmem was for assisting in debugging the kernel. We can use the device like a regular character device, using lseek() to select an address offset. The kmem device is similar but provides an image of kernel memory in the context of virtual addressing. The Xorg server makes use of the mem device to access VESA video memory as well as the BIOS ROM Interrupt Vector Table (IVT) located at physical address 0x00000000 to manipulate video modes in VM86 mode. DOSEMU also uses this to access the BIOS IVT to be able to make BIOS Interrupts for various tasks (disk reads, printing to the console, etc).

References

  • How to dump memory image from linux system?
  • How do I dump physical memory in Linux?
  • Master boot record
  • Compaq Computer Corporation Phoenix Technologies Ltd. Intel Corporation BIOS Boot Specification Version 1.01 January 11, 1996
  • Linux Memory Analysis - forensic wiki
  • X86 Assembly/Bootloaders

Tags:

Memory

X86

Recent Posts