>> It was looked at, and as you can see, fsirand(8) is already in the
>> tree.  I believe the completion of this is currently stalled on a
>> good /dev/random implementation.

> Uh, but ... how are you going to get high-bandwidth randomness to do
> anything useful and `strongly random' with an entire partition worth
> of inodes -- 9 Gigabytes or more, for some installations?

It seems to me that fsirand is going about it wrong.

What are inode generation numbers for?

They serve two functions: (1) to permit proper ESTALE errors on clients
when appropriate and (2) to make file handles hard to guess de novo.

Unfortunately, these two goals are in conflict.  The former requires
that an inode generation count repeat as seldom as possible, which
implies something effectively akin to using it as a counter, whereas
the second is best served by making the generation field completely
random (which opens up the danger of birthday collisions making trouble
for the first purpose).

Neither purpose calls for anything to be done at newfs time (except for
inode 2); it can all be done at inode allocation time, since the
generation count on an unallocated inode is irrelevant (any file handle
that appears to refer to an unallocated inode is either forged or stale
and deserves ESTALE).  Current generation numbers are 32 bits, which is
enough for either (1) or (2) but is a bit small to serve for both at
once.  My preferred tack would be to use di_gen to address (1), by
incrementing it every time the inode is allocated (or alternatively,
every time it's deallocated), then either steal one of the di_spare
fields to address (2) or take back di_u for the purpose, re-randomizing
this each time the inode is allocated (or deallocated).  This needs
almost nothing at newfs time but needs a source of randomness during
operation, to randomize the anti-guessing field.  While this ideally
should use cryptographically strong random numbers, I don't consider
that essential; even something as weak as random(3) would be of at
least some value here.  Even if they are theoretically guessable, they
will stop a high enough proportion of the attacks to be useful.  (I
really think we shouldn't avoid doing something like this that will
stop 90% or so just because it won't stop the remaining 10%.)

Seeding this RNG at boot time is a Hard Problem, but even if it doesn't
get strongly seeded it's not worse than what we have now, so I would
like to see it go in even before we have strong randomness available to
drive it.

> Last, since the current fsirand is so FFS-specific, and has to be run
> on clean filesystems, the FS-specific fsck back-end (fsck_ffs) might
> be a better place to put the functionality -- or even newfs.

See above - I think it should go into the kernel; only inode 2 needs
any special attention from newfs, and that only because it never gets
freed and reallocated.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B