[Cryptography] RFC possible changes for Linux random device

[Peter Gutmann]

Theodore Ts'o <tytso at mit.edu> writes:

>P.S.  Oh, and if anyone can get the ARM architecture folks to specify a cycle
>counter which is guaranteed to be there, or at the very least, won't crash
>the SOC if you try to use it and it's not there --- which is why Linux
>doesn't try to use the cycle counter at all on most ARM platforms, even
>though it's often present (it's just that it's not guaranteed by the ARM
>architecture, and if you guess wrong, the results are catastrophic) --- that
>would be awfully nice. 

+1.  The SoC vendors like to advertise all the cool hardware features they
have, but (at least for the ones that would be useful in a crypto context) you
can't use them for exactly the reason you describe.  So you end up in a
perverse situation where if you've got some deeply embedded system (ICS, bread
makers, washing machines) where the hardware never changes over a 10-15 year
period you can safely assume the presence of crypto-related features that
you'll never need or use, but if you're building something more flexible that
does need the crypto features then you can't use any of them because you don't
know whether they'll crash the system or not.  As a result, you have to treat
everything like a basic ARMv3 from the 1990s.

>a lot more about engineering and politics and negotiating with hardware
>vendors who are worried about shaving millicents off of their BOM cost....

Is it a BOM issue thought?  A feature-test mechanism like CPUID essentially
comes free with the CPU, and in fact adding IP that can't be reliably used
would seem to come with a negative cost.  I've always assumed (for lack of a
more sensible reason) that it was a case of "only our SoC exists and no-one
else's" (with a side-order of "lalala I'm not listening"), "so we'll force the
creation of binaries that don't work on anything else".

Peter.