On the i686 platform, the bootloader incorrectly handles memory map entries that exceed the 4GB boundary. Even though both the kernel and the bootloader support PAE, the bootloader truncates or skips entries above the 32-bit address space limit. This leads to a significant loss of usable system memory. In scenarios with a large MMIO hole, the available RAM reported to the kernel can drop as low as 2GB, even if the system has 4GB or more installed.
The issue is centered in the Memory::MapEfiMemory() function within memory.cc. The current implementation contains a condition that discards or truncates memory descriptors if their physical address or length exceeds the 32-bit limit. Simply removing the conditional check is insufficient. The mapping logic currently relies on architecture-dependent types such as PVOID and ULONG_PTR. On i686, these types are 32-bit wide, making them incapable of holding or processing physical addresses above the 0xFFFFFFFF.
Impact:
Systems with >4GB of RAM cannot utilize the extra memory despite PAE support.
Due to hardware-reserved ranges (MMIO), the "visible" memory below 4GB is often significantly less than the actual physical RAM, and the bootloader fails to recover the reclaimed memory above the 4GB mark.
To resolve this, the memory mapping logic must be decoupled from architecture-specific pointer widths.
On the i686 platform, the bootloader incorrectly handles memory map entries that exceed the 4GB boundary. Even though both the kernel and the bootloader support PAE, the bootloader truncates or skips entries above the 32-bit address space limit. This leads to a significant loss of usable system memory. In scenarios with a large MMIO hole, the available RAM reported to the kernel can drop as low as 2GB, even if the system has 4GB or more installed.
The issue is centered in the Memory::MapEfiMemory() function within memory.cc. The current implementation contains a condition that discards or truncates memory descriptors if their physical address or length exceeds the 32-bit limit. Simply removing the conditional check is insufficient. The mapping logic currently relies on architecture-dependent types such as PVOID and ULONG_PTR. On i686, these types are 32-bit wide, making them incapable of holding or processing physical addresses above the 0xFFFFFFFF.
**Impact:**
- Systems with >4GB of RAM cannot utilize the extra memory despite PAE support.
- Due to hardware-reserved ranges (MMIO), the "visible" memory below 4GB is often significantly less than the actual physical RAM, and the bootloader fails to recover the reclaimed memory above the 4GB mark.
To resolve this, the memory mapping logic must be decoupled from architecture-specific pointer widths.
harraiken
added the BUG label 2025-12-23 19:41:32 +01:00
harraiken
self-assigned this 2026-01-08 20:35:19 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
On the i686 platform, the bootloader incorrectly handles memory map entries that exceed the 4GB boundary. Even though both the kernel and the bootloader support PAE, the bootloader truncates or skips entries above the 32-bit address space limit. This leads to a significant loss of usable system memory. In scenarios with a large MMIO hole, the available RAM reported to the kernel can drop as low as 2GB, even if the system has 4GB or more installed.
The issue is centered in the Memory::MapEfiMemory() function within memory.cc. The current implementation contains a condition that discards or truncates memory descriptors if their physical address or length exceeds the 32-bit limit. Simply removing the conditional check is insufficient. The mapping logic currently relies on architecture-dependent types such as PVOID and ULONG_PTR. On i686, these types are 32-bit wide, making them incapable of holding or processing physical addresses above the 0xFFFFFFFF.
Impact:
To resolve this, the memory mapping logic must be decoupled from architecture-specific pointer widths.
9ed851ed1fPR #24
Fixed by ##24