linux-kernel - Re: [PATCH] fix Intel RNG detection

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: <44C8F4E5.76E4.0078.0@novell.com>
Date:	Thu, 27 Jul 2006 16:16:21 +0100
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Michael Buesch" <mb@...sch.de>
Cc:	<jgarzik@...ox.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fix Intel RNG detection

>> +#ifdef CONFIG_SMP
>> +static volatile char __initdata waitflag;
>
>I don't think we want to add yet another use of volatile
>(see the kernel archives for why).
>Use memory barriers instead, please.

I can certainly do that.

>> +#define waitflag err
>
>That's really confusing magic.

Any better idea? I just wanted to prevent adding another #ifdef CONFIG_SMP, and since it doesn't matter where the write
goes for UP, doing it that way seemed the simplest solution.

>> +	writeb(0xff, mem);
>> +	writeb(0x90, mem);
>> +	mfg = readb(mem + 0);
>> +	dvc = readb(mem + 1);
>> +	writeb(0xff, mem);
>
>Do these magic registers have names? Possible to use #defines for it?

While one could certainly make up names for them (the documentation of the functionality used here isn't the best I've
seen), I generally dislike creating defines when their values are used just in a single place *and* when their naming
can at best be artificial (i.e. doesn't serve documentation purposes). But if you and/or Jeff insist, I can certainly do
a change like that.

Jan

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