On Wed, 2011-09-07 at 17:43 -0400, Steve Grubb wrote: > On Wednesday, September 07, 2011 05:35:18 PM Jarod Wilson wrote: > > Another proposal that has been kicked around: a 3rd random chardev, > > which implements this functionality, leaving urandom unscathed. Some > > udev magic or a driver param could move/disable/whatever urandom and put > > this alternate device in its place. Ultimately, identical behavior, but > > the true urandom doesn't get altered at all. > > Right, and that's what I was trying to say is that if we do all that and switch out > urandom with something new that does what we need, what's the difference in just > patching the behavior into urandom and calling it a day? Its simpler, less fragile, > admins won't make mistakes setting up the wrong one in a chroot, already has the > FIPS-140 dressing, and is auditable. Whats the difference between changing the behavior of a well defined interface (/dev/urandom) which may cause userspace applications to fail, in opposed to a non-intrusive usermode CUSE driver which can do exactly what you need (and more - if more is required in the future)? None, none at all... CUSE supports kernel auditing, admins making mistakes is hardly the kernels' problem (unless it makes it easy for them to do mistakes) and code moved into the kernel doesn't suddenly become more stable and simpler. -- Sasha. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
