linux-kernel - Re: [PATCH v2 0/3] support for broken memory modules (BadRAM)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E035DD1.1030603@kpanic.de>
Date:	Thu, 23 Jun 2011 17:37:53 +0200
From:	Stefan Assmann <sassmann@...nic.de>
To:	Matthew Garrett <mjg59@...f.ucam.org>
CC:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, tony.luck@...el.com,
	andi@...stfloor.org, mingo@...e.hu, hpa@...or.com,
	rick@...rein.org, rdunlap@...otime.net
Subject: Re: [PATCH v2 0/3] support for broken memory modules (BadRAM)

On 23.06.2011 16:12, Matthew Garrett wrote:
> On Thu, Jun 23, 2011 at 04:08:32PM +0200, Stefan Assmann wrote:
>> On 23.06.2011 15:39, Matthew Garrett wrote:
>>> Would it be more reasonable to do this in the bootloader? You'd ideally 
>>> want this to be done as early as possible in order to avoid awkward 
>>> situations like your ramdisk ending up in the bad RAM area.
>>
>> Not sure what exactly you are suggesting here. The kernel somehow needs
>> to know what memory areas to avoid so we supply this information via
>> kernel command line.
>> What the bootloader could do is to allow the kernel/initrd to be loaded
>> at an alternative address. That's briefly mentioned in the BadRAM
>> Documentation as well. Is that what you mean or am I missing something?
> 
> For EFI booting we just hand an e820 map to the kernel. It ought to be 
> easy enough to add support for that to the 16-bit entry point as well. 
> Then the bootloader just needs to construct an e820 map of its own. I 
> think grub2 actually already has some support for this. The advantage of 
> this approach is that the knowledge of bad memory only has to exist in 
> one place (ie, the bootloader) - the kernel can remain blisfully 
> unaware.
> 

According to Rick's reply in this thread a damaged row in a DIMM can
easily cause a few thousand entries in the e820 table because it doesn't
handle patterns. So the question I'm asking is, is it acceptable to
have an e820 table with thousands maybe ten-thousands of entries?
I really have no idea of the implications, maybe somebody else can
comment on that.

  Stefan
--
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/