From: Ingo Molnar <mingo@elte.hu>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Philipp Kohlbecher <xt28@gmx.de>, Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: alternative identifier for Phoenix BIOS
Date: Tue, 18 Nov 2008 16:06:59 +0100 [thread overview]
Message-ID: <20081118150659.GF30358@elte.hu> (raw)
In-Reply-To: <20081116111447.23fbfe7e@lxorguk.ukuu.org.uk>
* 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
next prev parent reply other threads:[~2008-11-18 15:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-15 15:42 [PATCH] x86: alternative identifier for Phoenix BIOS Philipp Kohlbecher
2008-11-16 1:55 ` H. Peter Anvin
2008-11-16 7:23 ` Ingo Molnar
2008-11-16 11:11 ` [PATCH v2] x86: more general " Philipp Kohlbecher
2008-11-18 15:12 ` Ingo Molnar
2008-11-16 11:14 ` [PATCH] x86: alternative " Alan Cox
2008-11-18 15:06 ` Ingo Molnar [this message]
2008-11-16 16:51 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081118150659.GF30358@elte.hu \
--to=mingo@elte.hu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=xt28@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.