Skip to contentSkip to conversation

x86: alternative identifier for Phoenix BIOS

PATCH Superseded Philipp Kohlbecher 5 participants 8 messages Nov 15, 2008 – Nov 18, 2008 x86

lore
Share & tools
lore

Philipp Kohlbecher

author
#0 lore raw

PATCH 1/1 x86: alternative identifier for Phoenix BIOS

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 <[email protected]>

---

Please CC me, I am not on the list.

 arch/x86/kernel/setup.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
arch/x86/kernel/setup.c +0 -0
index 0fa6790..b88fdbe 100644
@@ -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
     {}

};

reviewer
#1 lore raw
Quoted 6 lines · 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).

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

#2 lore raw
Quoted 8 lines · H. Peter Anvin
Quoted 7 lines · 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).

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.

Quoted 3 lines

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

author
#3 lore raw

PATCH v2 1/1 x86: more general identifier for Phoenix BIOS

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 <[email protected]>

---

 arch/x86/kernel/setup.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/x86/kernel/setup.c +1 -1
index 0fa6790..9d5674f 100644
@@ -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
Quoted 9 lines · Ingo Molnar
Quoted 4 lines · H. Peter Anvin
Quoted 3 lines · 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).

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.)

#5 lore raw
In reply to H. Peter Anvin
Quoted 11 lines · On Sat, 15 Nov 2008 17:55:20 -0800 "H. Peter Anvin" <[email protected]> wrote:
Quoted 6 lines · 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).

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

#7 lore raw
In reply to H. Peter Anvin
Quoted 11 lines · H. Peter Anvin
Quoted 6 lines · 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).

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.

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#6 lore raw
In reply to Alan Cox
Quoted 23 lines · Alan Cox
Quoted 11 lines · On Sat, 15 Nov 2008 17:55:20 -0800 "H. Peter Anvin" <[email protected]> wrote:
Quoted 6 lines · 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).

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.

Quoted 2 lines

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

Applied
#4 lore raw

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

In reply to Philipp Kohlbecher
Quoted 11 lines · 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 <[email protected]>

applied to tip/x86/urgent, thanks Philipp!

I also tagged it for -stable backporting.

Quoted 6 lines
Quoted 3 lines

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