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]
Date:	Fri, 23 Jul 2010 20:21:16 +0200
From:	"Mario 'BitKoenig' Holbe" <Mario.Holbe@...Ilmenau.DE>
To:	"John W. Linville" <linville@...driver.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: b43 wireless driver inhibits access to /dev/hwrng

On Fri, Jul 23, 2010 at 01:32:46PM -0400, John W. Linville wrote:
> Alright, sorry I overlooked that.  Although it still looks to me like
> your current_rng must be the b43-provided one, or else you wouldn't
> be experiencing this issue.

Yes. Unfortunately, the b43 module is loaded earlier than the via-rng
module: the former gets loaded via udev autodetection, the latter gets
loaded via my /etc/modules. Thus, the rng core selects b43 as the
"current" RNG.

> > I guess, b43 just stops delivering data through b43_rng_read() when the
> > hardware is shut down and instead returns ENODEV (which is btw. what I
> > get when I'm trying to read /dev/hwrng while b43 is down), and the rng
> Yes, I believe this is what the b43 hwrng is doing.  I suspect you
> need/want a way to influence current_rng to favor via-rng.  You may

Yes, once knowing what happens it was easy to find a work-around:

root@...apad ~ # cat /etc/modprobe.d/local-b43-workaround.conf
# Work-around: b43 provides a Hardware RNG as well, but returns ENODEV
# on read() when the BCM4312 hardware is down.
# Ensure via-rng is loaded before this module. This way hw_random/core
# delivers read()s on /dev/hwrng to via-rng.
install b43 modprobe via-rng; modprobe --ignore-install b43 $CMDLINE_OPTS

> want to reference Documentation/hw_random.txt for further information.

Indeed, setting /sys/devices/virtual/misc/hw_random/rng_current would
probably be a cleaner solution :) Thanks for that.

However, I still somehow feel like this is a bug - either in the rng
core or in b43. One of both should IMHO be changed: either the rng core
to respect drivers not currently delivering data or (probably cleaner)
to provide an interface to suspend a driver, or the b43 driver to
unregister its rng when the hardware is shut down (or power it up when
the rng is accessed? probably a bit oversized :)).

Unfortunately, Documentation/hw_random.txt has no usage guidelines for
the rng core, i.e. how drivers should behave when no data is available.
It talks about a `hardware "has-data" flag', but I cannot find such a
thing in the code.


Thanks for your help and patience
   Mario
-- 
File names are infinite in length where infinity is set to 255 characters.
                                -- Peter Collinson, "The Unix File System"

Download attachment "signature.asc" of type "application/pgp-signature" (483 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ