A couple of months ago Paolo Bonzini reported a bug in the early 32-bit EFI code on x86. While the bug looked legitimate, I was initially stumped as to how he was triggering it in the first place, and perhaps more importantly, why no one else had hit this issue before.

It turns out that the values loaded into the x86 descriptor table registers (IDT, GDTR) are not actually accessed when they registers are written - they're only used when performing other operations, such as handling interrupts in the case of the IDT or modifying the segment registers in the case of LDTR and GDTR. So, if you write a completely bogus value into GDTR it will not affect execution until you receive an interrupt. That does explain why no one hit this issue earlier... interrupts were always disabled during execution with the buggy IDT value until very recently.

The flow of execution used to go like this, 

static efi_status_t  __init phys_efi_set_virtual_address_map(...)
{
        disable_interrupts();
        switch_page_tables(new_pgtable);
        load_gdt(new_gdt_addr); 
        SetVirtualAddressMap();
        switch_page_tables(orig_pgtable);
        enable_interrupts();
}
After commit 23a0d4e8fa the following order of events was possible, 

static efi_status_t  __init phys_efi_set_virtual_address_map(...)
{
        
        switch_page_tables(new_pgtable);
        load_gdt(new_gdt_addr); 
        <INTERRUPT> --> crash!
        disable_interrupts();
        SetVirtualAddressMap()
        enable_interrupts();
        switch_page_tables(orig_pgtable);
}
An important point to note is that it is the loading of the new page tables that renders the GDT address invalid - we weren't actually loading an incorrect address, it's just that the address wasn't mapped in the new page tables. Disabling interrupts throughout the entire execution of phys_efi_set_virtual_address_map() masked this bug for years.