linux-kernel - Re: [RFC] amd64_edac: syndromes loading

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: <20091105132758.GC17984@aftab>
Date:	Thu, 5 Nov 2009 14:27:58 +0100
From:	Borislav Petkov <borislav.petkov@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Pavel Machek <pavel@....cz>, Doug Thompson <norsk5@...oo.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, x86 <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] amd64_edac: syndromes loading

Hi,

sorry for the delay, I had to talk to the hardware guys about those
tables.

On Mon, Nov 02, 2009 at 07:33:14AM +0900, H. Peter Anvin wrote:
> >>Alternatively, we could make the syndromes builtin thus removing the
> >>requirement to go to userspace for the loading. For that we'll need
> >>two new .c files in drivers/edac/ which represent the x4 and x8 tables
> >>respectively:
> >>
> >>unsigned short x8_raw_data[] = {
> >>         0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> >>         0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> >>         0x0000, 0x0100, 0x0001, 0x0101, 0x01B8, 0x015C, 0x012E, 0x01C6, 0x0163,
> >>         0x01FD, 0x0189, 0x019D, 0xB801, 0x5C01, 0x2E01, 0xC601, 0x6301, 0xFD01,
> >>         0x8901, 0x9D01, 0x0200, 0x0002, 0x0202, 0x0201, 0x02B8, 0x025C, 0x02FD,
> >>	....
> >>
> >>The drawback with these is that they'll always be builtin, enlarging
> >>kernel code by 10-15K although only one of them is in use.
> >
> >I believe that 15K is reasonable price to pay for not having to
> >install another 'firmware' file.
> 
> a) aren't these computable somehow?  If so, it's probably easier to
> include the algorithm in the kernel rather than a table.

That's a no-go since it would involve IP disclosure.

> b) "I believe that 15K is reasonable price to pay for not having to
> install another 'firmware' file."  I think that's a tradeoff a lot
> of people would *not* choose to make.  This is of course why we have
> (or at least, should have) to either compile in firmware blobs or
> not.

The good news is they've come up with a modified algorithm which will
require a smaller table, roughly 1/4th the size of the current 10K one.
Now, on a second thought and IMHO, we should simply add another .c file
instantiating those two x4 and x8 tables statically and linking them
into the edac code. This way you

1) don't have the additional complexity of adding firmware handling code
and thus don't add a dependency on the firmware API

2) don't have to actually carry two firmware images with the kernel

See, the natural use case for those tables are big machines which do not
care about 4K memory wasted in ECC decoding tables when the recovery
from the missed early warnings of a failing DIMM module is much more
expensive.

Hmm... ?

-- 
Regards/Gruss,
Boris.

Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632

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