You should see a longer help text for this config option. It offers two reasons.
int "Amount of low memory, in kilobytes, to reserve for the BIOS"
range 4 640
Specify the amount of low memory to reserve for the BIOS.
The first page contains BIOS data structures that the kernel
must not use, so that page must always be reserved.
There is a similar comment in the code:
* A special case is the first 4Kb of memory;
* This is a BIOS owned area, not kernel ram, but generally
* not listed as such in the E820 table.
The traditional BIOS would use the first 1280 bytes (0x500). Linux allocates RAM in units of the MMU page size (4096 bytes). OSDev points out -
After all the BIOS functions have been called, and your kernel is loaded into memory somewhere, the bootloader or kernel may exit Real Mode forever (often by going into 32bit Protected Mode). If the kernel never uses Real Mode again, then the first 0x500 bytes of memory in the PC may be reused and overwritten.
Linux is not generally able to call into the BIOS. However it may do so in a few terrifying moments: early boot, shutdown, and resume from sleep mode. If your system was booted using UEFI, then as far as Linux can tell there is no BIOS it can call.
Also, reserving the first page means that successful physical memory allocations never return the value 0. C programming traditionally reserves the address 0 to represent a "NULL pointer". We can see this reflected in memblock_phys_alloc_range(). At this point, changing it seems unlikely to repay the effort (and the risks :-).
* Return: physical address of the allocated memory block on success,
* %0 on failure.
phys_addr_t __init memblock_phys_alloc_range(
Here is the second reason:
By default we reserve the first 64K of physical RAM, as a
number of BIOSes are known to corrupt that memory range
during events such as suspend/resume or monitor cable
insertion, so it must not be used by the kernel.
You can set this to 4 if you are absolutely sure that you
trust the BIOS to get all its memory reservations and usages
right. If you know your BIOS have problems beyond the
default 64K area, you can set this to 640 to avoid using the
entire low memory range.
If you have doubts about the BIOS (e.g. suspend/resume does
not work or there's kernel crashes after certain hardware
hotplug events) then you might want to enable
X86_CHECK_BIOS_CORRUPTION=y to allow the kernel to check
typical corruption patterns.
Leave this to the default value of 64 if you are unsure.
The safest assumption is that this could apply to UEFI firmware as well, just as it did to BIOS :-).
Since v3.9, the extra low reserve is
not shown in the kernel log messages. It is also not shown in
/proc/iomem. The kernel only shows the first 4k reserved, even though the rest of the memory should still be reserved. It is just not added in the e820 map. It is added to a different list instead. The patch for this change is here: x86, mm: Move reserving low memory later in initialization.
If you want to find out more about the extra reservation, and the tale of woe that required it, here are the patch messages:
Alan Jenkins and Andy Wettstein reported a suspend/resume memory
corruption bug and extensively documented it here:
The bug is that the BIOS overwrites 1K of memory at 0xc000 physical,
without registering it in e820 as reserved or giving the kernel any
idea about this.
Detect AMI BIOSen and reserve that 1K.
We paint this bug around with a very broad brush (reserving that 1K
on all AMI BIOS systems), as the bug was extremely hard to find and
needed several weeks and lots of debugging and patching.
The bug was found via the CONFIG_X86_CHECK_BIOS_CORRUPTION=y debug
feature, if similar bugs are suspected then this feature can be
enabled on other systems as well to scan low memory for corrupted
Documents a wide range of systems where the BIOS utilizes the first
64K of physical memory during suspend/resume and other hardware
Currently we reserve this memory on all AMI and Phoenix BIOS systems.
Life is too short to hunt subtle memory corruption problems like this,
so we try to be robust by default.
Still, allow this to be overriden: allow users who want that first 64K
of memory to be available to the kernel disable the quirk, via
The laundry list of BIOSes that need the low 64K reserved is getting
very long, so make it the default across all BIOSes. This also allows
the code to be simplified and unified with the reservation code for
the first 4K.
This resolves kernel bugzilla 16661 and who knows what else...
[...] It means we should add his BIOS (dmidecode info please) to the blacklist bad_bios_dmi_table in arch/x86/kernel/setup.c. However, the bottom line is that 64K is such a small amount of memory and the list by now covers such a vast number of existing BIOSes, that we should just make it unconditional.
As far as I know, Windows 7 actually reserves all memory below 1 MiB to avoid BIOS bugs.