-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
I just removed the network device entropy-generating patches from the kernel repo. They had to be explicitly enabled for use and were consistently refused for upstream acceptance. With no better hardware entropy source, they kept the pool full but are prone to third party manipulation via packet flooding.
I noticed that since 11.4, we have installed haveged by default. Might it be a good idea to enable it by default as well? Perhaps someone with more experience with it can chime in, but it looks like it stays dormant until the entropy pool drops too low so there's not a lot of overhead.
- -Jeff
- -- Jeff Mahoney SUSE Labs
El 06/05/11 20:59, Jeff Mahoney escribió:
Hi all -
I just removed the network device entropy-generating patches from the kernel repo. They had to be explicitly enabled for use and were consistently refused for upstream acceptance. With no better hardware entropy source, they kept the pool full but are prone to third party manipulation via packet flooding.
I noticed that since 11.4, we have installed haveged by default. Might it be a good idea to enable it by default as well? Perhaps someone with more experience with it can chime in, but it looks like it stays dormant until the entropy pool drops too low so there's not a lot of overhead.
Open a bug report and assign it to me, I will check it out, CC the security team also plz ;)
While you are at it, there is an havege kernel module [1] as well, but currently does not compile/work, any hope of taking a look on it ?
[1] http://www.irisa.fr/caps/projects/hipsor/scripts/down.php?id=7176208&ext...
Finally I got a question, why crypto devices that can feed the kernel entropy pool automatically have to use rngd ? I know something should check for the quality of that entropy, I wonder why the kernel itself doesnt do that tests.
El 06/05/11 21:29, Cristian Rodríguez escribió:
Finally I got a question, why crypto devices that can feed the kernel entropy pool automatically have to use rngd ? I know something should check for the quality of that entropy, I wonder why the kernel itself doesnt do that tests.
For example, machines that have a wireless card, using the b43 driver, may have the ability to use the hwrng built on the chip automatically,yet the user has to know how to setup rngd and deal with the fact that if you put the interface down, rngd will go kaput. :|
This is the epitome of user-unfriendlyness, yet pretty much everything uses entropy in one way of other,without the user having a single clue about it.
Cheers.
On 05/06/2011 08:29 PM, Cristian Rodríguez wrote:
El 06/05/11 20:59, Jeff Mahoney escribió:
Hi all -
I just removed the network device entropy-generating patches from the kernel repo. They had to be explicitly enabled for use and were consistently refused for upstream acceptance. With no better hardware entropy source, they kept the pool full but are prone to third party manipulation via packet flooding.
I noticed that since 11.4, we have installed haveged by default. Might it be a good idea to enable it by default as well? Perhaps someone with more experience with it can chime in, but it looks like it stays dormant until the entropy pool drops too low so there's not a lot of overhead.
Open a bug report and assign it to me, I will check it out, CC the security team also plz ;)
Please add me as well.
While you are at it, there is an havege kernel module [1] as well, but currently does not compile/work, any hope of taking a look on it ?
[1] http://www.irisa.fr/caps/projects/hipsor/scripts/down.php?id=7176208&ext...
If we need help from upstream, ping me off-list. I used to work with these folks and know some of them personally.
Finally I got a question, why crypto devices that can feed the kernel entropy pool automatically have to use rngd ? I know something should check for the quality of that entropy, I wonder why the kernel itself doesnt do that tests.
Cheers,
Peter
On Fri, 06 May 2011 22:00:52 -0300 Cristian Rodríguez crrodriguez@opensuse.org wrote:
This is the epitome of user-unfriendlyness, yet pretty much everything uses entropy in one way of other,without the user having a single clue about it.
Well, kernel hackers started "put everything in userspace that does not absolutely need to be in the kernel" some years ago. The system became user-unfriendly but nobody cared. Then they noticed that this made booting slow (among others), and started putting things back into the kernel.
Actually, the Master Pinguin seems to be not the biggest friend of "make everything more complicated to setup for everyone by putting stuff in userspace". He delivered a classic rant about userspace suspend for example :-)
So probably a good way to get this fixed is to rant loudly on linux-kernel, until it gets Linus' attention. I can well imagine that he'll be in favor of an "just work by default without complicated userspace setup" solution. Having some patches ready surely also will not hurt :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/06/2011 09:00 PM, Cristian Rodríguez wrote:
El 06/05/11 21:29, Cristian Rodríguez escribió:
Finally I got a question, why crypto devices that can feed the kernel entropy pool automatically have to use rngd ? I know something should check for the quality of that entropy, I wonder why the kernel itself doesnt do that tests.
For example, machines that have a wireless card, using the b43 driver, may have the ability to use the hwrng built on the chip automatically,yet the user has to know how to setup rngd and deal with the fact that if you put the interface down, rngd will go kaput. :|
This is the epitome of user-unfriendlyness, yet pretty much everything uses entropy in one way of other,without the user having a single clue about it.
That sounds more like a problem with rngd if the it dies when the interface goes down.
- -Jeff
- -- Jeff Mahoney SUSE Labs
El 07/05/11 11:21, Jeff Mahoney escribió:
That sounds more like a problem with rngd if the it dies when the interface goes down.
Not actually my point.
I'm convinced that the task of managing entropy generated by crypto devices supported by the kernel is kernel's business,exposing a /dev/hwrng device an let to user to manage it is not a solution.
VIA hardware comes with an rng, yet the user has to know about it. AFAIK future intel processors will as well.
And let's not mention the hw crypto accelerators, like AES-NI which are supported by both the kernel and openssl but pretty much nothing uses it due to this mentality of "is up to the callee/user" that plagues us.
:-|
-
Cristian Rodríguez -
Jeff Mahoney -
Peter Linnell -
Stefan Seyfried