linux-kernel - Re: [PATCH RFC #2] hwrng: Add type categories

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:	Wed, 27 Jun 2007 14:03:31 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Michael Buesch <mb@...sch.de>
Cc:	Matt Mackall <mpm@...enic.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC #2] hwrng: Add type categories

On Wed, 27 Jun 2007, Michael Buesch wrote:
> Well, we have that userspace ABI of one hwrng char device. I did not

Yeah.  Talk about shortsighted ABIs that deserve to die an horrible death.
The same goes for the watchdog ABI.

> And changing it in a compatible way is probably difficult.

Well, sort of.  Some sort of compromise will have to be taken.

IMHO, anything worth bothering with in userspace will react well to a
symlink in /dev/hw_random, which is userspace's problem to set.  Anyone else
is expected to fix his /dev or whatever when they upgrade kernels, and we
can always provide the old hw_random char device returning EFAULT or
somesuch, so that it becomes very obvious that something is in need of
attention (and it FAILS instead of just disappearing).

> And then we would _still_ export some kind of hint for rngd that
> the CPU rng device should be preferred over the bcm43xx device.

Yes, export all the characterisitics of the RNG, and let userspace decide
what to do.

> How would you implement that? (We're back to my TYPE_XXX definitions ;) )

I'd implement it as an IOCTL with gives back:

1. Hardware device name
2. Hardware device revision
3. expected worst-case minimum entropy per bit of output
4. current config expected minimum entropy per bit of output
5. average bit rate (worst config)
6. average bit rate (current config)

There are probably others, but they don't come to mind at the moment.  We
could add something for type of device (oscilators, radioactive decay,
whatever), I suppose.

Use some magic value (0x00 ?) for unknown.  I won't bother with the scales,
if someone is going to write this, we can decide that later.  Just remember
that there are 10 Mbit/s RNGs out there, and 100 bit/s RNGs out there, and
that entropy goes from 0/unknown to 1 and needs at least a precison of
10^-3.

You also need a way to lock the RNG configuration, and you need to detect if
you ever read a byte from it that was produced by a different
configuration, which probably means a few more IOCTLs.

> What is "vital information"? My TYPE_XXX categories? ;)

See above.

> It _can_. We can switch the RNG in sysfs. So userspace _can_ get data
> from whichever HWRNG it wants.

I don't much like sysfs over IOCTLs for this, as you will probably need to
be able to set and get things in an atomic way.  A sysfs binary attribute
would also work.  A sysfs one-value-per-attribute bunch of them is
completely useless from a security point of view.

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