Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1462771 > unrolled thread

Re: [PATCH] x86/efi-bgrt: remove the check of the version field

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] x86/efi-bgrt: remove the check of the version field Matt Fleming <matt@codeblueprint.co.uk> - 2016-08-15 15:10 +0200
    Re: [PATCH] x86/efi-bgrt: remove the check of the version field Josh Triplett <josh@joshtriplett.org> - 2016-08-15 18:20 +0200
    Re: [PATCH] x86/efi-bgrt: remove the check of the version field Dave Young <dyoung@redhat.com> - 2016-08-17 07:50 +0200
      Re: [PATCH] x86/efi-bgrt: remove the check of the version field Matt Fleming <matt@codeblueprint.co.uk> - 2016-08-19 03:50 +0200
        Re: [PATCH] x86/efi-bgrt: remove the check of the version field Dave Young <dyoung@redhat.com> - 2016-08-22 09:40 +0200
          Re: [PATCH] x86/efi-bgrt: remove the check of the version field Dave Young <dyoung@redhat.com> - 2016-08-24 09:40 +0200

#1462771 — Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote:
> Some broken firmwares have a wrongly filled version field in BGRT table.
> (See http://wiki.osdev.org/Broken_UEFI_implementations )
> 
> As we know, these firmwares can also provide correct BGRT image, although
> the table is wrong.
> 
> After removing the check of the version field, the kernel can now extract
> the image correctly, and the information is also correct.
> 
> Tested on a Thinkpad E531 (68854UC).
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>  arch/x86/platform/efi/efi-bgrt.c | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
> index 6a2f569..f492ea0 100644
> --- a/arch/x86/platform/efi/efi-bgrt.c
> +++ b/arch/x86/platform/efi/efi-bgrt.c
> @@ -47,11 +47,6 @@ void __init efi_bgrt_init(void)
>  		       bgrt_tab->header.length, sizeof(*bgrt_tab));
>  		return;
>  	}
> -	if (bgrt_tab->version != 1) {
> -		pr_notice("Ignoring BGRT: invalid version %u (expected 1)\n",
> -		       bgrt_tab->version);
> -		return;
> -	}
>  	if (bgrt_tab->status & 0xfe) {
>  		pr_notice("Ignoring BGRT: reserved status bits are non-zero %u\n",
>  		       bgrt_tab->status);

This would be less scary if we checked for known broken and known good
version values instead of removing the check altogether, i.e. 0 and 1.

The whole point of the version field is that it tells us about the
layout of the BGRT table, so it's not exactly a useless check.

[toc] | [next] | [standalone]

#1462966

On Mon, Aug 15, 2016 at 01:56:43PM +0100, Matt Fleming wrote:
> On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote:
> > Some broken firmwares have a wrongly filled version field in BGRT table.
> > (See http://wiki.osdev.org/Broken_UEFI_implementations )
> > 
> > As we know, these firmwares can also provide correct BGRT image, although
> > the table is wrong.
> > 
> > After removing the check of the version field, the kernel can now extract
> > the image correctly, and the information is also correct.
> > 
> > Tested on a Thinkpad E531 (68854UC).
> > 
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > ---
> >  arch/x86/platform/efi/efi-bgrt.c | 5 -----
> >  1 file changed, 5 deletions(-)
> > 
> > diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
> > index 6a2f569..f492ea0 100644
> > --- a/arch/x86/platform/efi/efi-bgrt.c
> > +++ b/arch/x86/platform/efi/efi-bgrt.c
> > @@ -47,11 +47,6 @@ void __init efi_bgrt_init(void)
> >  		       bgrt_tab->header.length, sizeof(*bgrt_tab));
> >  		return;
> >  	}
> > -	if (bgrt_tab->version != 1) {
> > -		pr_notice("Ignoring BGRT: invalid version %u (expected 1)\n",
> > -		       bgrt_tab->version);
> > -		return;
> > -	}
> >  	if (bgrt_tab->status & 0xfe) {
> >  		pr_notice("Ignoring BGRT: reserved status bits are non-zero %u\n",
> >  		       bgrt_tab->status);
> 
> This would be less scary if we checked for known broken and known good
> version values instead of removing the check altogether, i.e. 0 and 1.
> 
> The whole point of the version field is that it tells us about the
> layout of the BGRT table, so it's not exactly a useless check.

Agreed.  It seems likely that BIOSes would have incorrectly left the
version at 0.  It seems less likely that they'd set it to some other
random value.

So, I'd suggest changing the check to pr_debug and continue for 0,
continue for 1, and pr_notice and abort for anything else.

[toc] | [prev] | [next] | [standalone]

#1464331

On 08/15/16 at 01:56pm, Matt Fleming wrote:
> On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote:
> > Some broken firmwares have a wrongly filled version field in BGRT table.
> > (See http://wiki.osdev.org/Broken_UEFI_implementations )
> > 
> > As we know, these firmwares can also provide correct BGRT image, although
> > the table is wrong.
> > 
> > After removing the check of the version field, the kernel can now extract
> > the image correctly, and the information is also correct.
> > 
> > Tested on a Thinkpad E531 (68854UC).
> > 
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > ---
> >  arch/x86/platform/efi/efi-bgrt.c | 5 -----
> >  1 file changed, 5 deletions(-)
> > 
> > diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
> > index 6a2f569..f492ea0 100644
> > --- a/arch/x86/platform/efi/efi-bgrt.c
> > +++ b/arch/x86/platform/efi/efi-bgrt.c
> > @@ -47,11 +47,6 @@ void __init efi_bgrt_init(void)
> >  		       bgrt_tab->header.length, sizeof(*bgrt_tab));
> >  		return;
> >  	}
> > -	if (bgrt_tab->version != 1) {
> > -		pr_notice("Ignoring BGRT: invalid version %u (expected 1)\n",
> > -		       bgrt_tab->version);
> > -		return;
> > -	}
> >  	if (bgrt_tab->status & 0xfe) {
> >  		pr_notice("Ignoring BGRT: reserved status bits are non-zero %u\n",
> >  		       bgrt_tab->status);
> 
> This would be less scary if we checked for known broken and known good
> version values instead of removing the check altogether, i.e. 0 and 1.

Could we add some quirk for these broken hardware instead of changing
the normal code?

> 
> The whole point of the version field is that it tells us about the
> layout of the BGRT table, so it's not exactly a useless check.

Agreed.

Thanks
Dave

[toc] | [prev] | [next] | [standalone]

#1465841

On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> 
> Could we add some quirk for these broken hardware instead of changing
> the normal code?

I'd prefer not to do that if possible. Due to the way that the BIOS
ecosystem works, this kind of broken firmware spreads across the
industry, appearing in newer versions of products from the same vendor
and even products from different vendors.

Continuously updating a quirks table as additional broken platforms
are discovered simply does not scale.

[toc] | [prev] | [next] | [standalone]

#1467424

On 08/18/16 at 09:41pm, Matt Fleming wrote:
> On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> > 
> > Could we add some quirk for these broken hardware instead of changing
> > the normal code?
> 
> I'd prefer not to do that if possible. Due to the way that the BIOS
> ecosystem works, this kind of broken firmware spreads across the
> industry, appearing in newer versions of products from the same vendor
> and even products from different vendors.
> 
> Continuously updating a quirks table as additional broken platforms
> are discovered simply does not scale.

Ok, I assumed that they are limited like one point in the web url
http://wiki.osdev.org/Broken_UEFI_implementations 

But I arm probably wrong like you said. Please ignore the comment then.

Thanks
Dave

[toc] | [prev] | [next] | [standalone]

#1469134

On 08/22/16 at 04:49pm, Icenowy Zheng wrote:
> 
> 
> 22.08.2016, 15:28, "Dave Young" <dyoung@redhat.com>:
> > On 08/18/16 at 09:41pm, Matt Fleming wrote:
> >>  On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> >>  >
> >>  > Could we add some quirk for these broken hardware instead of changing
> >>  > the normal code?
> >>
> >>  I'd prefer not to do that if possible. Due to the way that the BIOS
> >>  ecosystem works, this kind of broken firmware spreads across the
> >>  industry, appearing in newer versions of products from the same vendor
> >>  and even products from different vendors.
> >>
> >>  Continuously updating a quirks table as additional broken platforms
> >>  are discovered simply does not scale.
> >
> > Ok, I assumed that they are limited like one point in the web url
> > http://wiki.osdev.org/Broken_UEFI_implementations
> 
> At least I think all Thinkpads suffer from this.

Icenowy, sorry for late reply, I missed it. I'm not sure other version, but my
T440s does work well.

> 
> >
> > But I arm probably wrong like you said. Please ignore the comment then.
> >

Thanks
Dave

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web