#1135596 ipxe: in Bookworm i386, cannot load ipxe binary due to incorrect compile flags

Package:
ipxe
Source:
ipxe
Submitter:
Martin-Éric Racine
Date:
2026-05-03 21:07:03 UTC
Severity:
normal
Tags:
#1135596#5
Date:
2026-05-03 10:59:14 UTC
From:
To:
Bookworm's base level for the i386 architecture is 686. However, the binary seemingly is compiled for 686-pae. It fails to boot and crashes the CPU. Recovering requires unplugging the power cord and restarting the host. Please upload binaries compiled with the correct flags to bookworm-security.

Thanks!
Martin-Éric

#1135596#10
Date:
2026-05-03 15:56:26 UTC
From:
To:
I'm not ipxe maintainer, but it feels like bookworm is now
in history, unless a security issue is found.

Besides that, bookworm-security feels definitely wrong for
a bug/fix like you're requesting.

FWIW,

/mjt

#1135596#15
Date:
2026-05-03 21:05:32 UTC
From:
To:
Hi,

Thanks for your report. However, I cannot reproduce what you have claimed about
the iPXE binary in bookworm. You stated that during the execution of one of the
iPXE binaries, it tries to use PAE, i.e., Physical Address Extension, and when
the CPU does not support PAE, the boot fails and CPU crashes. I believe it is
of little probability, due to the following aspects of reasons.

1. PAE cannot be used without setting the corresponding flags of CPU
controlling registers. In our case, the enabling of PAE is controlled by bit 5
of CR4. In the level of the source, by searching in the source code for the
related statements, such statements can only be found in the functions[1]
prot_to_long and long_to_prot, which are used to switch between 32 bit
protected mode 64 bit long mode. These functions are surrounded by a macro
`.if64`, which means that these code will not be included in 32-bit builds.
As a result, it can be expected that no such code enabling PAE will go into
the compiled binaries for legacy bios boot.

2. Testing the binary on an emulated i686 CPU without PAE shows that the iPXE
boatloader work as intended. The following qemu commands are used to carry out
the tests:

  1. Download the following packages:
       ipxe_1.0.0+git-20190125.36a4c85-5.1_all.deb,
       linux-image-6.1.0-45-amd64_6.1.170-1_amd64.deb,
       linux-image-6.1.0-45-686-pae_6.1.170-1_i386.deb,
       linux-image-6.1.0-45-686_6.1.170-1_i386.deb
     and unpack them to get all the kernels and bootloaders for tests
  2. Install qemu-system-x86 in sid
  3. Executing qemu-system-i386 -cpu pentium2 -machine pc \
       -smp cpus=1,cores=1,sockets=1 -m 1G  -nographic \
       -chardev stdio,mux=on,id=char0  -monitor chardev:char0 \
       -serial chardev:char0 -kernel ./boot/vmlinuz-6.1.0-45-amd64 \
       -append "console=ttyS0,115200n8"
     shows "This kernel requires an x86-64 CPU, but only detected an i686 CPU.",
     confirming x86_64 is not supported by qemu-system-i386
  4. Executing qemu-system-i386 -cpu pentium2 -machine pc \
       -smp cpus=1,cores=1,sockets=1 -m 1G  -nographic \
       -chardev stdio,mux=on,id=char0  -monitor chardev:char0 \
       -serial chardev:char0 -kernel ./boot/vmlinuz-6.1.0-45-686-pae \
       -append "console=ttyS0,115200n8"
     confirms PAE kernels can correctly boot on this type of emulated CPU.
  5. Executing qemu-system-i386 -cpu pentium2,-pae -machine pc \
       -smp cpus=1,cores=1,sockets=1 -m 1G  -nographic \
       -chardev stdio,mux=on,id=char0  -monitor chardev:char0 \
       -serial chardev:char0 -kernel ./boot/vmlinuz-6.1.0-45-686-pae \
       -append "console=ttyS0,115200n8"
     shows "This kernel requires the following features not present on the CPU:
     pae", confirming adding "-pae" to "-cpu" flags correctly disables the PAE
     functionality.
  6. Executing qemu-system-i386 -cpu pentium2,-pae -machine pc \
       -smp cpus=1,cores=1,sockets=1 -m 1G  -nographic \
       -chardev stdio,mux=on,id=char0  -monitor chardev:char0 \
       -serial chardev:char0 -kernel ./boot/vmlinuz-6.1.0-45-686 \
       -append "console=ttyS0,115200n8"
     confirms non-PAE kernels can correctly boot when PAE is disabled.
  7. Executing qemu-system-i386 -cpu pentium2,-pae -machine pc \
       -smp cpus=1,cores=1,sockets=1 -m 1G  -nographic \
       -chardev stdio,mux=on,id=char0  -monitor chardev:char0 \
       -serial chardev:char0 -kernel ./boot/ipxe.lkrn
     confirms that iPXE works normally when PAE is disabled.

3. Further hooking on the CR4 handling function in qemu shows during the
execution of iPXE, PAE is never enabled. The following gdb commands are used
to carry out this test:

  1. Download debug symbols of qemu, and use gdb to open the qemu-system-i386
     executable
  2. Set a breakpoint on the function cpu_x86_update_cr4:
       br cpu_x86_update_cr4
  3. When the breakpoint is hit, automatically run the following commands to
     print the old value and the new value of the PAE bit:
       commands
         silent
         printf "cpu_x86_update_cr4: 0x%08x -> 0x%08x\n", \
           env->cr[4] & 0x20, new_cr4 & 0x20
         continue
       end
  4. Start the pae kernel to confirm the above commands can correctly reflect
     the change of the PAE bit:
       r -cpu pentium2 -machine pc -smp cpus=1,cores=1,sockets=1 -m 1G  \
       -nographic -chardev stdio,mux=on,id=char0  -monitor chardev:char0 \
       -serial chardev:char0 -kernel ./boot/vmlinuz-6.1.0-45-686-pae \
       -append "console=ttyS0,115200n8"
     >> cpu_x86_update_cr4: 0x00000000 -> 0x00000020
  5. Start the iPXE bootloader to confirm the PAE bit has never been enabled:
       r -cpu pentium2,-pae -machine pc -smp cpus=1,cores=1,sockets=1 -m 1G  \
       -nographic -chardev stdio,mux=on,id=char0  -monitor chardev:char0 \
       -serial chardev:char0 -kernel ./boot/ipxe.lkrn

As a result, I cannot reproduce what you have claimed. You may further
describe the problem you have met, especially the condition that triggers
the crash. You may also provide any clues about what makes the binary
seem to be "compiled for 686-pae".

I agree with mjt.

Even though the iPXE boot loader fails to boot and lead to crash on
certain CPUs, I don't think it is a security issue, since it is not
possible for a malicious actor to gain control of a host or make any
damage without first gaining root privileges.

In the meantime, the (old)stable-security is beyond the control of
package maintainer, but is within the control of the security team.
If you do believe this is a security issue, please directly contact
them.

Cheers,

Miao Wang


[1]: https://sources.debian.org/src/ipxe/1.0.0%2Bgit-20190125.36a4c85-5.1/src/arch/x86/transitions/librm.S#L743