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: <BANLkTim2yoYFTG4MZxv7KH1ujTV2h5c+LHb8hCp2dHCqZvbKYA@mail.gmail.com>
Date:	Fri, 24 Jun 2011 07:35:55 -0700
From:	Craig Bergstrom <craigb@...gle.com>
To:	unlisted-recipients:; (no To-header on input)
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/3] support for broken memory modules (BadRAM)

On Fri, Jun 24, 2011 at 1:05 AM, Rick van Rein <rick@...rein.org> wrote:
>
> Hi Craig,
>
> > We (Google) are working on a data-driven answer for this question.  I know
> > that there has been some analysis on this topic on the past, but I don't
> > want to speculate until we've had some time to put all the pieces together.
>
> The easiest way to do this could be to take the algorithm from Memtest86
> and apply it to your data, to see if it finds suitable patterns for the
> cases tried.
>
> By counting bits set to zero in the masks, you could then determine how
> 'tight' they are.  A mask with all-ones covers one memory page; each
> zero bit in the mask (outside of the CPU's page size) doubles the number
> of pages covered.
>
> You can ignore the address over which the mask is applied, although you
> would then be assuming that all the pages covered by the mask are indeed
> filled with RAM.
>
> You would want to add the figures for the different masks.

This seems like a reasonable approach.  I know there was some analysis
done, and I'm doing my best to get the folks who made the original
decision to weigh in.

>
> I am very curious about your findings.  Independently of those, I am in
> favour of a patch that enables longer e820 tables if it has no further
> impact on speed or space.

I think that we'd all be satisfied with a mechanism that allows for
badram to be specified via both command line and an extended e820 map.

>
>
> Cheers,
>  -Rick
--
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/