On Wednesday 27 June 2007 19:03:31 Henrique de Moraes Holschuh wrote: > 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.
Ok, all very good ideas. Patches are welcome ;) > 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. hm? Why? -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
