I am not sure if this question should go here or in reverseengineering.stackexchange.com

Quoting from wikipedia:

In the 8086 processor, the interrupt table is called IVT (interrupt vector table). The IVT always resides at the same location in memory, ranging from 0x0000 to 0x03ff, and consists of 256 four-byte real mode far pointers (256 × 4 = 1024 bytes of memory).

This is what I find in qemu monitor:

(qemu) xp/128xw 0
0000000000000000: 0xf000ff53 0xf000ff53 0xf000e2c3 0xf000ff53
0000000000000010: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000020: 0xf000fea5 0xf000e987 0xf000d62c 0xf000d62c
0000000000000030: 0xf000d62c 0xf000d62c 0xf000ef57 0xf000d62c
0000000000000040: 0xc0005526 0xf000f84d 0xf000f841 0xf000e3fe
0000000000000050: 0xf000e739 0xf000f859 0xf000e82e 0xf000efd2
0000000000000060: 0xf000d648 0xf000e6f2 0xf000fe6e 0xf000ff53
0000000000000070: 0xf000ff53 0xf000ff53 0xf0006aa4 0xc0008930
0000000000000080: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000090: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000a0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000b0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000c0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000d0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000e0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000f0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000100: 0xf000ec59 0xf000ff53 0xf000ff53 0xc0006730
0000000000000110: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000120: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000130: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000140: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000150: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000160: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000170: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000180: 0x00000000 0x00000000 0x00000000 0x00000000
0000000000000190: 0x00000000 0x00000000 0x00000000 0xf000ff53
00000000000001a0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000001b0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000001c0: 0xf000d611 0xf000ec4e 0xf000ec4e 0xf000ec4e
00000000000001d0: 0xf000d61a 0xf000d623 0xf000d608 0xf000ec4e
00000000000001e0: 0xf000ff53 0x00000000 0xf000ff53 0xf000ff53
00000000000001f0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53

I am not sure what to make of those values. It does not look like an interrupt descriptor table (dereferencing those values gives all nulls). So what am I actually looking at here?


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

  • No, I mean what I wrote. Intel Architecture Software Developers' Manual volume 3 chapter 20 § 2. – JdeBP Aug 17 '18 at 13:53
  • Well you have now, because it is; as the first sentence of that section explains. I suspect from this that non-recognition of the common abbreviation "v8086" is a sort of shibboleth. (-: – JdeBP Aug 17 '18 at 14:21
  • You need to learn how to read attributive nouns. Or else learn to live without mushroom soup. – JdeBP Aug 22 '18 at 13:41

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.

  • This makes sense. Any idea what the leftover content in that unused page is from? – rhodeo Aug 10 '18 at 7:08
  • Googling for 53 ff reveals that this is most likely actually a 8086 Real Mode interrupt vector table set up by the firmware or a boot loader. – Johan Myréen Aug 10 '18 at 10:34

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  |U.@.b...........|
000c0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 49 42  |..............IB|


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


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.


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



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.