From: "Yinghai Lu" <yhlu.kernel@gmail.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "Ingo Molnar" <mingo@elte.hu>, "Rafał Miłecki" <zajec5@gmail.com>,
"Alan Jenkins" <alan-jenkins@tuffmail.co.uk>,
"Hugh Dickens" <hugh@veritas.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] x86: check for and defend against BIOS memory corruption
Date: Thu, 28 Aug 2008 18:49:49 -0700 [thread overview]
Message-ID: <86802c440808281849nb972d64te89894077ea9f33c@mail.gmail.com> (raw)
In-Reply-To: <48B701FB.2020905@goop.org>
On Thu, Aug 28, 2008 at 12:52 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Some BIOSes have been observed to corrupt memory in the low 64k. This> patch does two things:> - Reserves all memory which does not have to be in that area, to> prevent it from being used as general memory by the kernel. Things> like the SMP trampoline are still in the memory, however.> - Clears the reserved memory so we can observe changes to it.> - Adds a function check_for_bios_corruption() which checks and reports on> memory becoming unexpectedly non-zero. Currently it's called in the> x86 fault handler, and the powermanagement debug output.>> RFC: What other places should we check for corruption in?>> [ Alan, Rafał: could you check you see:> 1: corruption messages> 2: no crashes> Thanks -J> ]>> Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>> Cc: Hugh Dickens <hugh@veritas.com>> Cc: Ingo Molnar <mingo@elte.hu>> Cc: Rafael J. Wysocki <rjw@sisk.pl>> Cc: Rafał Miłecki <zajec5@gmail.com>> Cc: H. Peter Anvin <hpa@zytor.com>> ---> Documentation/kernel-parameters.txt | 5 ++> arch/x86/Kconfig | 3 +> arch/x86/kernel/setup.c | 86 +++++++++++++++++++++++++++++++++++> arch/x86/mm/fault.c | 2> drivers/base/power/main.c | 1> include/linux/kernel.h | 12 ++++> 6 files changed, 109 insertions(+)>> ===================================================================> --- a/Documentation/kernel-parameters.txt> +++ b/Documentation/kernel-parameters.txt> @@ -359,6 +359,11 @@> BayCom Serial Port AX.25 Modem (Half Duplex Mode)> Format: <io>,<irq>,<mode>> See header of drivers/net/hamradio/baycom_ser_hdx.c.> +> + bios_corruption_check=0/1 [X86]> + Some BIOSes seem to corrupt the first 64k of memory> + when doing things like suspend/resume. Setting this> + option will scan the memory looking for corruption.>> boot_delay= Milliseconds to delay each printk during boot.> Values larger than 10 seconds (10000) are changed to> ===================================================================> --- a/arch/x86/Kconfig> +++ b/arch/x86/Kconfig> @@ -203,6 +203,9 @@> bool> depends on X86_SMP || (X86_VOYAGER && SMP) || (64BIT && ACPI_SLEEP)> default y> +> +config X86_CHECK_BIOS_CORRUPTION> + def_bool y>> config KTIME_SCALAR> def_bool X86_32> ===================================================================> --- a/arch/x86/kernel/setup.c> +++ b/arch/x86/kernel/setup.c> @@ -582,6 +582,88 @@> struct x86_quirks *x86_quirks __initdata = &default_x86_quirks;>> /*> + * Some BIOSes seem to corrupt the low 64k of memory during events> + * like suspend/resume and unplugging an HDMI cable. Reserve all> + * remaining free memory in that area and fill it with a distinct> + * pattern.> + */> +#ifdef CONFIG_X86_CHECK_BIOS_CORRUPTION> +#define MAX_SCAN_AREAS 8> +static struct e820entry scan_areas[MAX_SCAN_AREAS];> +static int num_scan_areas;> +> +static void __init setup_bios_corruption_check(void)> +{> + u64 addr = PAGE_SIZE; /* assume first page is reserved anyway */> +
can you please not punish systems without this bios problem?
if (!bios_corruption_check) return;
> + while(addr < 0x10000 && num_scan_areas < MAX_SCAN_AREAS) {> + u64 size;> + addr = find_e820_area_size(addr, &size, PAGE_SIZE);> +> + if (addr == 0)> + break;> +> + if ((addr + size) > 0x10000)> + size = 0x10000 - addr;> +> + if (size == 0)> + break;> +> + e820_update_range(addr, size, E820_RAM, E820_RESERVED);> + scan_areas[num_scan_areas].addr = addr;> + scan_areas[num_scan_areas].size = size;> + num_scan_areas++;> +> + /* Assume we've already mapped this early memory */> + memset(__va(addr), 0, size);> +> + addr += size;> + }> +> + printk(KERN_INFO "scanning %d areas for BIOS corruption\n",> + num_scan_areas);> + update_e820();> +}> +> +static int __read_mostly bios_corruption_check = 1;
move earlier andbios_corruption_check = 0;
BTW: SMI evil damaged that area?
YH˙ôčş{.nÇ+ˇŽ+%Ë˙ąéÝś\x17Ľw˙ş{.nÇ+ˇĽ{ąţGŤé˙{ayş\x1dĘÚë,j\a˘fŁ˘ˇhďę˙ęçz_čŽ\x03(éݢj"ú\x1aś^[m§˙˙ž\aŤţGŤé˙˘¸?¨čÚ&Łř§~áśiOćŹzˇvŘ^\x14\x04\x1aś^[m§˙˙Ă\f˙śě˙˘¸?IĽ
next prev parent reply other threads:[~2008-08-29 1:50 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-28 19:52 [PATCH RFC] x86: check for and defend against BIOS memory corruption Jeremy Fitzhardinge
2008-08-29 1:49 ` Yinghai Lu [this message]
2008-08-29 3:28 ` Jeremy Fitzhardinge
2008-08-29 9:25 ` Alan Cox
2008-08-29 10:13 ` Rafał Miłecki
2008-08-29 10:06 ` Alan Cox
2008-08-29 10:24 ` Hugh Dickins
2008-08-29 11:54 ` Rafał Miłecki
2008-08-29 12:09 ` Alan Jenkins
2008-08-29 13:21 ` Hugh Dickins
2008-08-29 16:30 ` Rafał Miłecki
2008-08-29 17:39 ` Rafał Miłecki
2008-09-04 19:42 ` Rafał Miłecki
2008-09-04 20:23 ` Hugh Dickins
2008-09-04 23:04 ` Jeremy Fitzhardinge
2008-09-06 18:09 ` Ingo Molnar
2008-08-29 14:08 ` Jeremy Fitzhardinge
2008-08-29 14:18 ` Jeremy Fitzhardinge
2008-08-29 20:31 ` Kasper Sandberg
2008-08-30 1:15 ` Jeremy Fitzhardinge
2008-08-29 6:20 ` Rafał Miłecki
2008-08-29 6:45 ` Ingo Molnar
2008-08-29 7:21 ` Jeremy Fitzhardinge
2008-08-29 7:30 ` Ingo Molnar
2008-08-29 8:02 ` Jeremy Fitzhardinge
2008-08-29 7:22 ` Jeremy Fitzhardinge
2008-08-29 8:14 ` Hugh Dickins
2008-08-29 14:48 ` Jeremy Fitzhardinge
2008-08-29 17:20 ` H. Peter Anvin
2008-09-08 11:35 ` Hugh Dickins
2008-09-08 17:16 ` Jeremy Fitzhardinge
2008-09-08 19:14 ` Hugh Dickins
2008-09-08 19:45 ` Jeremy Fitzhardinge
2008-08-29 17:02 ` H. Peter Anvin
2008-08-29 17:03 ` H. Peter Anvin
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=86802c440808281849nb972d64te89894077ea9f33c@mail.gmail.com \
--to=yhlu.kernel@gmail.com \
--cc=alan-jenkins@tuffmail.co.uk \
--cc=hpa@zytor.com \
--cc=hugh@veritas.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=zajec5@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).