"54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s

"54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s

[Koen Kooi]

Hi,

After updating from 3.14-rc7 to a recent git the kernel fails to boot on my thinkpad t440s and displays:

	Failed to get file info size
	Failed to alloc highmem for files

After a morning of running git bisect and rebooting, the bad commit seems to be:

	54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table

It doesn't revert cleanly, so I can't test current git without it to see if that fixes it or not. I'm using gummiboot as bootloader:

Boot Loader Binaries:
          ESP: /dev/disk/by-partuuid/47cab2d9-0641-476c-bc74-166b122fca15
         File: └─/EFI/gummiboot/gummibootx64.efi (gummiboot 44)
         File: └─/EFI/Boot/BOOTX64.EFI (gummiboot 44)

Boot Loader Entries in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0016
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/b7b4fad3-3d19-40fd-b341-0ec7f2152b81
         File: └─/EFI/gummiboot/gummibootx64.efi

        Title: Linux Boot Manager
           ID: 0x0015
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/47cab2d9-0641-476c-bc74-166b122fca15
         File: └─/EFI/gummiboot/gummibootx64.efi

        Title: Fedora
           ID: 0x0014
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/47cab2d9-0641-476c-bc74-166b122fca15
         File: └─/EFI/fedora/shim.efi

        Title: Windows Boot Manager
           ID: 0x0013
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/56dff960-86b5-4846-89d3-fed0620f471a
         File: └─/EFI/Microsoft/Boot/bootmgfw.efi

thanks,

Koen

Bisect log:

git bisect start
# good: [dcb99fd9b08cfe1afe426af4d8d3cbc429190f15] Linux 3.14-rc7
git bisect good dcb99fd9b08cfe1afe426af4d8d3cbc429190f15
# bad: [39de65aa2c3eee901db020a4f1396998e09602a3] Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect bad 39de65aa2c3eee901db020a4f1396998e09602a3
# bad: [ec0159503ae74aeb834e78366bdf4b9663ca1129] hwmon: (k10temp) Add support for AMD F16 M30h processor
git bisect bad ec0159503ae74aeb834e78366bdf4b9663ca1129
# bad: [675c354a95d5375153b8bb80a0448cab916c7991] Merge tag 'char-misc-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect bad 675c354a95d5375153b8bb80a0448cab916c7991
# bad: [3786075b5ebc8c4eaefd9e3ebf72883934fb64b3] Merge tag 'regulator-v3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect bad 3786075b5ebc8c4eaefd9e3ebf72883934fb64b3
# bad: [1ce235faa8fefa4eb7199cad890944c1d2ba1b3e] Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
git bisect bad 1ce235faa8fefa4eb7199cad890944c1d2ba1b3e
# good: [8c292f11744297dfb3a69f4a0bccbe4a6417b50d] Merge branch 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 8c292f11744297dfb3a69f4a0bccbe4a6417b50d
# bad: [e06df6a7eae1ab1ef4deb076aeeaed90e948e5c0] Merge branch 'x86-kaslr-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad e06df6a7eae1ab1ef4deb076aeeaed90e948e5c0
# good: [971eae7c99212dd67b425a603f1fe3b763359907] Merge branch 'sched-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 971eae7c99212dd67b425a603f1fe3b763359907
# bad: [204b0a1a4b92612c957a042df1a3be0e9cc79391] x86, efi: Abstract x86 efi_early calls
git bisect bad 204b0a1a4b92612c957a042df1a3be0e9cc79391
# bad: [3db4cafdfd05717dc939780134e53023a3c1f15f] x86/boot: Fix non-EFI build
git bisect bad 3db4cafdfd05717dc939780134e53023a3c1f15f
# bad: [0154416a71c2a84c3746c8dd8ed25287e36934d3] x86/efi: Add early thunk code to go from 64-bit to 32-bit
git bisect bad 0154416a71c2a84c3746c8dd8ed25287e36934d3
# good: [426e34cc4f6094cefe4f3175764cdf583128e7cd] x86/mm/pageattr: Always dump the right page table in an oops
git bisect good 426e34cc4f6094cefe4f3175764cdf583128e7cd
# good: [677703cef0a148ba07d37ced649ad25b1cda2f78] efi: Add separate 32-bit/64-bit definitions
git bisect good 677703cef0a148ba07d37ced649ad25b1cda2f78

Build command line:

cp defconfig-3.13 .config ; yes '' | make oldconfig ; make bzImage -j4 && sudo cp arch/x86_64/boot/bzImage /boot/vmlinuz-3.14 && sudo reboot--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s

[Matt Fleming]

On Thu, 10 Apr, at 12:43:43PM, Koen Kooi wrote:
> Hi,
> 
> After updating from 3.14-rc7 to a recent git the kernel fails to boot on my thinkpad t440s and displays:
> 
> 	Failed to get file info size
> 	Failed to alloc highmem for files
> 
> After a morning of running git bisect and rebooting, the bad commit seems to be:
> 
> 	54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table

Thanks for the report. Can you try this patch against Linus' tree?


diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 1e6146137f8e..280165524ee4 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -112,7 +112,7 @@ __file_size64(void *__fh, efi_char16_t *filename_16,
 	efi_file_info_t *info;
 	efi_status_t status;
 	efi_guid_t info_guid = EFI_FILE_INFO_ID;
-	u32 info_sz;
+	u64 info_sz;
 
 	status = efi_early->call((unsigned long)fh->open, fh, &h, filename_16,
 				 EFI_FILE_MODE_READ, (u64)0);
-- 
Matt Fleming, Intel Open Source Technology Center

Re: "54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s

[Koen Kooi]

Op 10 apr. 2014, om 14:11 heeft Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> het volgende geschreven:

> On Thu, 10 Apr, at 12:43:43PM, Koen Kooi wrote:
>> Hi,
>> 
>> After updating from 3.14-rc7 to a recent git the kernel fails to boot on my thinkpad t440s and displays:
>> 
>> 	Failed to get file info size
>> 	Failed to alloc highmem for files
>> 
>> After a morning of running git bisect and rebooting, the bad commit seems to be:
>> 
>> 	54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table
> 
> Thanks for the report. Can you try this patch against Linus' tree?

That indeed fixes it, so:

Tested-by: Koen Kooi <koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org>

regards,

Koen

> 
> 
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index 1e6146137f8e..280165524ee4 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -112,7 +112,7 @@ __file_size64(void *__fh, efi_char16_t *filename_16,
> 	efi_file_info_t *info;
> 	efi_status_t status;
> 	efi_guid_t info_guid = EFI_FILE_INFO_ID;
> -	u32 info_sz;
> +	u64 info_sz;
> 
> 	status = efi_early->call((unsigned long)fh->open, fh, &h, filename_16,
> 				 EFI_FILE_MODE_READ, (u64)0);
> -- 
> Matt Fleming, Intel Open Source Technology Center
> 

Re: "54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s

[Ingo Molnar]

* Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> wrote:

> On Thu, 10 Apr, at 12:43:43PM, Koen Kooi wrote:
> > Hi,
> > 
> > After updating from 3.14-rc7 to a recent git the kernel fails to boot on my thinkpad t440s and displays:
> > 
> > 	Failed to get file info size
> > 	Failed to alloc highmem for files
> > 
> > After a morning of running git bisect and rebooting, the bad commit seems to be:
> > 
> > 	54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table
> 
> Thanks for the report. Can you try this patch against Linus' tree?
> 
> 
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index 1e6146137f8e..280165524ee4 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -112,7 +112,7 @@ __file_size64(void *__fh, efi_char16_t *filename_16,
>  	efi_file_info_t *info;
>  	efi_status_t status;
>  	efi_guid_t info_guid = EFI_FILE_INFO_ID;
> -	u32 info_sz;
> +	u64 info_sz;

Might be prudent to do the same in __file_size32(), instead of 
truncating silently, especially is that function too has a u64 output 
AFAICS.

Also, while reviewing the file I noticed that there's "u32 fb_base", 
which is recovered like:

                status = __gop_query64(gop64, &info, &size, &fb_base);

but ->frame_buffer_base is u64. Is it always guaranteed u32?

Thanks,

	Ingo

Re: "54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s

[Matt Fleming]

On Fri, 11 Apr, at 09:20:44AM, Ingo Molnar wrote:
> 
> Might be prudent to do the same in __file_size32(), instead of 
> truncating silently, especially is that function too has a u64 output 
> AFAICS.
 
This change isn't required for __file_size32() because we only use that
function if the firmware is 32-bit. The signature of
EFI_FILE_PROTOCOL.GetInfo() looks like this,

  EFI_STATUS (*EFI_FILE_GET_INFO) (
	EFI_FILE_PROTOCOL *This,
	EFI_GUID 	  *InformationType,
	UINTN		  *BufferSize,
	void		  *Buffer
  );

UINTN translates to unsigned long, so for 32-bit firmware is u32. The
firmware will never write 64-bits to &info_sz in __file_size32().

> Also, while reviewing the file I noticed that there's "u32 fb_base", 
> which is recovered like:
> 
>                 status = __gop_query64(gop64, &info, &size, &fb_base);
> 
> but ->frame_buffer_base is u64. Is it always guaranteed u32?

Good catch. ->frame_buffer_base isn't always u32, but we only have u32
bits in which to store it (struct screen_info.lfb_base), so we
implicitly truncate it,

static efi_status_t
__gop_query64(struct efi_graphics_output_protocol_64 *gop64,

[...]

        *fb_base = mode->frame_buffer_base;

But you raise a good point - it would probably make more sense to
complain loudly if we get an address above 0xffffffff.

-- 
Matt Fleming, Intel Open Source Technology Center