Hi,
I have a problem with a 82801DB chipset, the intel-rng module refuses to
load with the following error:
intel_rng: FWH not detected
The problem is that there is almost no entropy available for
/dev/random, and so SSL operations take a loooooooong time.
I have tried to look at the intel-rng module, and added some debug code
to check for the command results:
intel_rng: mfc: 0x00ea (should be 0x0089)
intel_rng: dvc: 0x0045 (should be 0x00ac or 0x00ad)
intel_rng: FWH not detected
intel_rng: XXX Trying to continue anyway
intel_rng: hw_status: 0x00 (should contain 0x40)
Then, again a -ENODEV.
Tried with 2.6.19.4 and 2.6.22.3, no result. For what I can tell, 2.6.8
had no RNG but had more entropy available.
I'm not sure the mhat a hardware RNG is present, so I want to check.
How can I know if this motherboard contains a RNG ? (which seems not to
be the case). This is a MB for servers (with a compact flash slot), and
has no soudn card, for ex.
lshw shows:
description: Motherboard
product: i845GV-83628HF
Alternatively, how can I make more entropy available ? (other than
tricks like using find() or similar, I do not think this is a serious
solution for a server to run "find /" in a cron every minute ..).
Maybe I have not understood, but it seems that entropy generators try to
create a new device /dev/erandom, for ex, so it would need a
modification of applications to work.
Thanks for your help,
Pierre
lspci:
0000:00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC
Bridge (rev 02)
lspci -s 00:1f.0 -xxx
0000:00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC
Bridge (rev 02)
00: 86 80 c0 24 0f 00 80 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 40 00 00 10 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 81 40 00 00 10 00 00 00
60: 0c 0a 0b 05 d0 00 00 00 80 80 80 09 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 75 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 20 02 00 00 00 00 00 00 0d 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 55 55 41 05 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 86 21 00 00 02 0f 00 00 04 00 00 00 00 00 00 00
e0: 10 00 00 c0 00 00 0f 34 33 22 11 00 91 02 67 45
f0: 0f 00 60 00 00 00 00 00 60 0f 02 00 00 00 81 00
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.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
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 ..
Regards,
Pierre
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 [email protected]
Home Page: http://www.roberthancock.com/
> This leaves the main problem, which is the lack of entropy. Does anyone
> have an idea on how to solve this problem ?
If you have a spare audio-card lying around or maybe a tv-card/webcam or
so, give then:
http://www.vanheusden.com/aed/ (for audio)
http://www.vanheusden.com/ved/ (for video4linux)
a try.
And no, audio-entropyd won't fill up the entropy pool in a second, it
takes a while. And often video-entropyd bails out because of not enough
noise in the video-signal.
Folkert van Heusden
--
MultiTail er et flexible tool for ? kontrolere Logfiles og commandoer.
Med filtrer, farger, sammenf?ringer, forskeliger ansikter etc.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com