linux-kernel - Re: intel_rng: FWH not detected (and no entropy)

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

Date:	Thu, 23 Aug 2007 17:27:07 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Pierre Chifflier <p.chifflier@....fr>
Cc:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	linux-kernel@...r.kernel.org
Subject: Re: intel_rng: FWH not detected (and no entropy)

Pierre Chifflier wrote:
> On Thu, Aug 23, 2007 at 09:53:04AM -0300, Henrique de Moraes Holschuh wrote:
>> On Thu, 23 Aug 2007, Pierre Chifflier wrote:
>>> I'm not sure the mhat a hardware RNG is present, so I want to check.
>> Open the mobo, and locate all FLASH chips.  If one of them is a 82802AB or
>> 82802AC, then you *MIGHT* have an Intel FWH with a HRNG (some of the FWHs
>> have their RNGs disabled, and since Intel stopped guaranteeing the RNG is
>> there, they would install one such FWH in their boards just the same).  If
>> none are a 82802AB or 82802AC, you don't have an Intel FWH with a HRNG.
>>
>> Even if you had an Intel board that is known to sometimes have an Intel FWH
>> with an RNG, like the D875PBZ, that wouldn't mean much.  They could have
>> used an non-Intel equivalent part for that production run, for unknown
>> reasons.  You really have to check.
> 
> Well, I've seen nothing more than the 82801DB (which was listed in
> lspci). So maybe there is no HRNG :(
> 
> This leaves the main problem, which is the lack of entropy. Does anyone
> have an idea on how to solve this problem ?
> It appeared with recent kernels. For ex, 2.6.8 had an entropy pool
> always > 3000, while 2.6.18 and other recent kernels show ~ 150.
> 
> # sysctl kernel.random.poolsize
> kernel.random.poolsize = 4096
> # sysctl kernel.random.entropy_avail
> kernel.random.entropy_avail = 196
> 
> This is really annoying, since the box should also use SSL/TLS
> operations, and it will be real slow ..

I believe that the timing of network interrupts used to be used to 
provide entropy, however in later kernels this was taken out as it was 
thought unsafe, since an attacker could detect or control the timing of 
these packets and thus determine the contents of the entropy pool.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

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