lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 17 Oct 2013 11:57:54 -0700
From:	Olof Johansson <olof@...om.net>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Corrupted low memory in v3.9+

Hi Peter,

When booting a newer kernel on a Chromebox (Samsung SNB system,
coreboot firmware, verified boot and not using seabios), I get reports
of:

[    1.727520] Corrupted low memory at ffff880000002a90 (2a90 phys) = 100000000
[    1.734565] Corrupted low memory at ffff880000002a98 (2a98 phys) =
50000000000

I bisected it down to:

commit 95c9608478d639dcffc14ea47b31bff021a99ed1
Author: H. Peter Anvin <hpa@...or.com>
Date:   Thu Feb 14 14:02:52 2013 -0800

    x86, mm: Move reserving low memory later in initialization

    Move the reservation of low memory, except for the 4K which actually
    does belong to the BIOS, later in the initialization; in particular,
    after we have already reserved the trampoline.

    The current code locates the trampoline as high as possible, so by
    deferring the allocation we will still be able to reserve as much
    memory as is possible.  This allows us to run with reservelow=640k
    without getting a crash on system startup.


My config has:

CONFIG_X86_RESERVE_LOW=64

...but /proc/iomem says:

00000000-00000fff : reserved
00001000-0009ffff : System RAM
000a0000-000fffff : reserved
[...]


While before the above patch it said:

00000000-00000fff : reserved
00001000-0000ffff : reserved
00010000-0009ffff : System RAM
[...]

And the low memory checker never even ran before, since it had nothing
to check. Earlier the lower reserved region would be included in the
e820-reserved area if I read the code correctly, and now it's just
marked reserved by the memblock code.

I guess it could be argued either way whether this is a regression or
not; but at the end of the day we now have systems where this warning
pops when it didn't use to. :(


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ