Linux kernel EFI stub bug?

Linux kernel EFI stub bug?

[Michael Brown]

I think I've found a bug in the kernel's EFI boot stub.  Specifically, 
in arch/x86/boot/compressed/eboot.c, in make_boot_params():

    sys_table = (efi_system_table_t *)(unsigned long)efi_early->table;

This compiles and links (on my system) to

    mov    %rdi,0xe658(%rip)        # 0x3d16f0

The problem is that address 0x3d16f0 is beyond the end of the loaded 
kernel image:

    objdump -x shows:

     Sections:
     Idx Name   Size      VMA               LMA               File off  Algn
     0 .setup   000041e0  0000000000000200  0000000000000200  00000200  2**4
                CONTENTS, ALLOC, LOAD, READONLY, CODE
     1 .reloc   00000020  00000000000043e0  00000000000043e0  000043e0  2**0
                CONTENTS, ALLOC, LOAD, READONLY, DATA
     2 .text    003c0e90  0000000000004400  0000000000004400  00004400  2**4
                CONTENTS, ALLOC, LOAD, READONLY, CODE

giving an image end address of 0x4400+0x3c0e90=0x3c5290 (which matches 
the size of the bzImage file).

The upshot is that the kernel writes beyond the end of allocated memory, 
producing undefined behaviour.  (In my test case, it ends up corrupting 
the initramfs image, resulting in an unbootable kernel.)

The same problem seems to exist in efi_main():

    sys_table = _table;

    mov    %rdi,0xe1bb(%rip)        # 0x3d16f0

As far as I can tell, the underlying problem is that .bss variables in 
eboot.o end up with addresses beyond the end of the loaded kernel.

Any ideas?

Michael

Re: Linux kernel EFI stub bug?

[H. Peter Anvin]

On 07/09/2014 08:31 AM, Michael Brown wrote:
> I think I've found a bug in the kernel's EFI boot stub.  Specifically,
> in arch/x86/boot/compressed/eboot.c, in make_boot_params():
> 
>    sys_table = (efi_system_table_t *)(unsigned long)efi_early->table;
> 
> This compiles and links (on my system) to
> 
>    mov    %rdi,0xe658(%rip)        # 0x3d16f0
> 
> The problem is that address 0x3d16f0 is beyond the end of the loaded
> kernel image:
> 
>    objdump -x shows:
> 
>     Sections:
>     Idx Name   Size      VMA               LMA               File off  Algn
>     0 .setup   000041e0  0000000000000200  0000000000000200  00000200  2**4
>                CONTENTS, ALLOC, LOAD, READONLY, CODE
>     1 .reloc   00000020  00000000000043e0  00000000000043e0  000043e0  2**0
>                CONTENTS, ALLOC, LOAD, READONLY, DATA
>     2 .text    003c0e90  0000000000004400  0000000000004400  00004400  2**4
>                CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> giving an image end address of 0x4400+0x3c0e90=0x3c5290 (which matches
> the size of the bzImage file).
> 
> The upshot is that the kernel writes beyond the end of allocated memory,
> producing undefined behaviour.  (In my test case, it ends up corrupting
> the initramfs image, resulting in an unbootable kernel.)
> 
> The same problem seems to exist in efi_main():
> 
>    sys_table = _table;
> 
>    mov    %rdi,0xe1bb(%rip)        # 0x3d16f0
> 
> As far as I can tell, the underlying problem is that .bss variables in
> eboot.o end up with addresses beyond the end of the loaded kernel.
> 

I would think we need to have an unallocated section -- as is typical
for a .bss section -- so the image loader knows how much memory we are
going to use.  This could be complicated, as we export a whole lot of
memory management information in the bzImage format, but I'm not sure if
we can easily convey the same in PE/COFF.  Does anyone know if very
large aligments (2^21 bytes) is handled by existing pecoff loaders?

	-hpa

Re: Linux kernel EFI stub bug?

[Michael Brown]

On 09/07/14 16:37, H. Peter Anvin wrote:
>> As far as I can tell, the underlying problem is that .bss variables in
>> eboot.o end up with addresses beyond the end of the loaded kernel.
>
> I would think we need to have an unallocated section -- as is typical
> for a .bss section -- so the image loader knows how much memory we are
> going to use.  This could be complicated, as we export a whole lot of
> memory management information in the bzImage format, but I'm not sure if
> we can easily convey the same in PE/COFF.  Does anyone know if very
> large aligments (2^21 bytes) is handled by existing pecoff loaders?

It is possible to create a .bss section in the PE/COFF header: iPXE does 
this.  For example:

   objdump -x bin-x86_64-efi/ipxe.efi

    Sections:
    Idx Name   Size      VMA               LMA               File off  Algn
    0 .text    00081948  0000000000001000  0000000000001000  000002c0  2**4
               CONTENTS, ALLOC, LOAD, READONLY, CODE
    1 .rodata  0002bf5e  0000000000082960  0000000000082960  00081c20  2**2
               CONTENTS, ALLOC, LOAD, DATA
    2 .data    0001fdf0  00000000000ae8c0  00000000000ae8c0  000adb80  2**4
               CONTENTS, ALLOC, LOAD, DATA
    3 .bss     000a27ac  00000000000ce700  00000000000ce700  00000000  2**4
               ALLOC
    4 .reloc   00001388  0000000000170ec0  0000000000170ec0  000cd980  2**2
               CONTENTS, ALLOC, LOAD, READONLY, DATA
    5 .debug   00000040  0000000000172260  0000000000172260  000ced20  2**0
               CONTENTS, READONLY, DEBUGGING

If the bootloader is using the EFI handover protocol (rather than 
calling the PE entry point), how is it (currently) supposed to know how 
much memory to provide beyond the end of the bzImage file?

Michael

Re: Linux kernel EFI stub bug?

[H. Peter Anvin]

On 07/09/2014 08:44 AM, Michael Brown wrote:
> 
> It is possible to create a .bss section in the PE/COFF header: iPXE does
> this.  For example:
> 
>   objdump -x bin-x86_64-efi/ipxe.efi
> 
>    Sections:
>    Idx Name   Size      VMA               LMA               File off  Algn
>    0 .text    00081948  0000000000001000  0000000000001000  000002c0  2**4
>               CONTENTS, ALLOC, LOAD, READONLY, CODE
>    1 .rodata  0002bf5e  0000000000082960  0000000000082960  00081c20  2**2
>               CONTENTS, ALLOC, LOAD, DATA
>    2 .data    0001fdf0  00000000000ae8c0  00000000000ae8c0  000adb80  2**4
>               CONTENTS, ALLOC, LOAD, DATA
>    3 .bss     000a27ac  00000000000ce700  00000000000ce700  00000000  2**4
>               ALLOC
>    4 .reloc   00001388  0000000000170ec0  0000000000170ec0  000cd980  2**2
>               CONTENTS, ALLOC, LOAD, READONLY, DATA
>    5 .debug   00000040  0000000000172260  0000000000172260  000ced20  2**0
>               CONTENTS, READONLY, DEBUGGING
> 
> If the bootloader is using the EFI handover protocol (rather than
> calling the PE entry point), how is it (currently) supposed to know how
> much memory to provide beyond the end of the bzImage file?
> 

Since that means you are "bzImage aware" you can look at the fields for
this in the bzImage header: init_size, kernel_alignment,
relocatable_kernel, min_alignment, and pref_address.

(init_size is the important one, obviously, but a misaligned kernel may
require additional space for adjustment.)

	-hpa