[PATCH] x86: alternative identifier for Phoenix BIOS

[PATCH] x86: alternative identifier for Phoenix BIOS

[Philipp Kohlbecher]

My laptop (a Samsung X20) contains a Phoenix BIOS and would benefit from 
patch 1e22436eba84edfec9c25e5a25d09062c4f91ca9 (x86: reserve low 64K on 
AMI and Phoenix BIOS boxen).

However, according to /sys/class/dmi/id/bios_vendor, the BIOS identifies
its vendor as "Phoenix Technologies LTD" (sans the comma).

This patch adds the approptiate identifier to the bad_bios_dmi_table in
arch/x86/kernel/setup.c.

The patch compiles cleanly and has been tested successfully on my machine.

Signed-off-by: Philipp Kohlbecher <xt28@gmx.de>

---

Please CC me, I am not on the list.

  arch/x86/kernel/setup.c |    7 +++++++
  1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0fa6790..b88fdbe 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -767,6 +767,13 @@ static struct dmi_system_id __initdata
bad_bios_dmi_table[] = {
              DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
          },
      },
+    {
+        .callback = dmi_low_memory_corruption,
+        .ident = "Phoenix BIOS",
+        .matches = {
+            DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"),
+        },
+    },
  #endif
      {}
  };

Re: [PATCH] x86: alternative identifier for Phoenix BIOS

[H. Peter Anvin]

Philipp Kohlbecher wrote:
> My laptop (a Samsung X20) contains a Phoenix BIOS and would benefit from
> patch 1e22436eba84edfec9c25e5a25d09062c4f91ca9 (x86: reserve low 64K on
> AMI and Phoenix BIOS boxen).
> 
> However, according to /sys/class/dmi/id/bios_vendor, the BIOS identifies
> its vendor as "Phoenix Technologies LTD" (sans the comma).

Given that AMI and Phoenix combined is something like 80% of the BIOS
market, if not more, it might simply be easier to make it unconditional,
 or make it a whitelist instead.

	-hpa

Re: [PATCH] x86: alternative identifier for Phoenix BIOS

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> Philipp Kohlbecher wrote:
> > My laptop (a Samsung X20) contains a Phoenix BIOS and would 
> > benefit from patch 1e22436eba84edfec9c25e5a25d09062c4f91ca9 (x86: 
> > reserve low 64K on AMI and Phoenix BIOS boxen).
> > 
> > However, according to /sys/class/dmi/id/bios_vendor, the BIOS 
> > identifies its vendor as "Phoenix Technologies LTD" (sans the 
> > comma).

Note that we should do a simpler patch: just change the string to 
"Phoenix Technologies" and that will provide a proper match. (DMI 
matches work on substrings too)

Also, note that you can also force this behavior (and the checking) 
via CONFIG_X86_CHECK_BIOS_CORRUPTION=y - that will enable the 
reservation and a debug check regardless of DMI matches.

> Given that AMI and Phoenix combined is something like 80% of the 
> BIOS market, if not more, it might simply be easier to make it 
> unconditional, or make it a whitelist instead.

The (slim) hope would be for them to address the memory corruptions 
that have been reported. It can affect older Linux versions, etc. So 
we want to print the fact to the syslog, based on the DMI strings from 
the reports.

	Ingo

[PATCH v2] x86: more general identifier for Phoenix BIOS

[Philipp Kohlbecher]

Phoenix BIOSes variously identify their vendor as "Phoenix Technologies, 
LTD" or "Phoenix Technologies LTD" (without the comma.)

This patch makes the identification string in the bad_bios_dmi_table 
more general (following a suggestion by Ingo Molnar), so that both 
versions are handled.

Again, the patched file compiles cleanly and the patch has been tested 
successfully on my machine.

Signed-off-by: Philipp Kohlbecher <xt28@gmx.de>

---

  arch/x86/kernel/setup.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0fa6790..9d5674f 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -764,7 +764,7 @@ static struct dmi_system_id __initdata 
bad_bios_dmi_table[] = {
  		.callback = dmi_low_memory_corruption,
  		.ident = "Phoenix BIOS",
  		.matches = {
-			DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
+			DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies"),
  		},
  	},
  #endif

Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> wrote:
> 
>> Philipp Kohlbecher wrote:
>>> My laptop (a Samsung X20) contains a Phoenix BIOS and would 
>>> benefit from patch 1e22436eba84edfec9c25e5a25d09062c4f91ca9 (x86: 
>>> reserve low 64K on AMI and Phoenix BIOS boxen).
>>>
>>> However, according to /sys/class/dmi/id/bios_vendor, the BIOS 
>>> identifies its vendor as "Phoenix Technologies LTD" (sans the 
>>> comma).
> 
> Note that we should do a simpler patch: just change the string to 
> "Phoenix Technologies" and that will provide a proper match. (DMI 
> matches work on substrings too)
> 

Done. (I wasn't sure whether you were saying that *I* should write this 
simpler patch or that you would. Anyway, here it is.)

Re: [PATCH v2] x86: more general identifier for Phoenix BIOS

[Ingo Molnar]

* Philipp Kohlbecher <xt28@gmx.de> wrote:

> Phoenix BIOSes variously identify their vendor as "Phoenix Technologies,  
> LTD" or "Phoenix Technologies LTD" (without the comma.)
>
> This patch makes the identification string in the bad_bios_dmi_table  
> more general (following a suggestion by Ingo Molnar), so that both  
> versions are handled.
>
> Again, the patched file compiles cleanly and the patch has been tested  
> successfully on my machine.
>
> Signed-off-by: Philipp Kohlbecher <xt28@gmx.de>

applied to tip/x86/urgent, thanks Philipp!

I also tagged it for -stable backporting.

>> Note that we should do a simpler patch: just change the string to 
>> "Phoenix Technologies" and that will provide a proper match. (DMI 
>> matches work on substrings too)
>
> Done. (I wasn't sure whether you were saying that *I* should write 
> this simpler patch or that you would. Anyway, here it is.)

yeah, developers/users writing patches is always the preferred 
solution! It's the vector that spreads Linux development to new areas 
and new people.

	Ingo

Re: [PATCH] x86: alternative identifier for Phoenix BIOS

[Alan Cox]

On Sat, 15 Nov 2008 17:55:20 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:

> Philipp Kohlbecher wrote:
> > My laptop (a Samsung X20) contains a Phoenix BIOS and would benefit from
> > patch 1e22436eba84edfec9c25e5a25d09062c4f91ca9 (x86: reserve low 64K on
> > AMI and Phoenix BIOS boxen).
> > 
> > However, according to /sys/class/dmi/id/bios_vendor, the BIOS identifies
> > its vendor as "Phoenix Technologies LTD" (sans the comma).
> 
> Given that AMI and Phoenix combined is something like 80% of the BIOS
> market, if not more, it might simply be easier to make it unconditional,
>  or make it a whitelist instead.

Far more useful would be to make people aware of the problem. If the BIOS
is scribbling in the low 64K of RAM not just BIOS areas, and doing so
outside of ACPI marked areas they need to fix the BIOS ASAP. If they leave
their BIOSes randomly scribbling in operating system memory areas then as
with previous (hardware related) cases of vendors knowingly shipping
corrupting equipment they'll be building up a huge class action legal
liability.

As such making sure the vendor knows in a way they cannot deny is a very
useful activity.

Alan

Re: [PATCH] x86: alternative identifier for Phoenix BIOS

[Ingo Molnar]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Sat, 15 Nov 2008 17:55:20 -0800
> "H. Peter Anvin" <hpa@zytor.com> wrote:
> 
> > Philipp Kohlbecher wrote:
> > > My laptop (a Samsung X20) contains a Phoenix BIOS and would benefit from
> > > patch 1e22436eba84edfec9c25e5a25d09062c4f91ca9 (x86: reserve low 64K on
> > > AMI and Phoenix BIOS boxen).
> > > 
> > > However, according to /sys/class/dmi/id/bios_vendor, the BIOS identifies
> > > its vendor as "Phoenix Technologies LTD" (sans the comma).
> > 
> > Given that AMI and Phoenix combined is something like 80% of the BIOS
> > market, if not more, it might simply be easier to make it unconditional,
> >  or make it a whitelist instead.
> 
> Far more useful would be to make people aware of the problem. If the 
> BIOS is scribbling in the low 64K of RAM not just BIOS areas, and 
> doing so outside of ACPI marked areas they need to fix the BIOS 
> ASAP. If they leave their BIOSes randomly scribbling in operating 
> system memory areas then as with previous (hardware related) cases 
> of vendors knowingly shipping corrupting equipment they'll be 
> building up a huge class action legal liability.
> 
> As such making sure the vendor knows in a way they cannot deny is a 
> very useful activity.

CONFIG_X86_CHECK_BIOS_CORRUPTION=y will do that, it prints:

  Corrupted low memory at 0x1000 (4096 phys) = 0x1234
  Memory corruption detected in low memory
  < stack trace >

if enough distros turn it on (at least in their debug kernels) it 
creates the right kind of user pressure.

This debug feature to catch BIOS-generated low-memory corruption is 
already upstream.

	Ingo

Re: [PATCH] x86: alternative identifier for Phoenix BIOS

[Pavel Machek]

On Sat 2008-11-15 17:55:20, H. Peter Anvin wrote:
> Philipp Kohlbecher wrote:
> > My laptop (a Samsung X20) contains a Phoenix BIOS and would benefit from
> > patch 1e22436eba84edfec9c25e5a25d09062c4f91ca9 (x86: reserve low 64K on
> > AMI and Phoenix BIOS boxen).
> > 
> > However, according to /sys/class/dmi/id/bios_vendor, the BIOS identifies
> > its vendor as "Phoenix Technologies LTD" (sans the comma).
> 
> Given that AMI and Phoenix combined is something like 80% of the BIOS
> market, if not more, it might simply be easier to make it unconditional,
>  or make it a whitelist instead.

Whitelist is bad:

even if bios vendor is a good boy and tests their bios with linux,
they will not notice that they corrupt low 64K (not whitelisted), and
will not fix their bios.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html