[Cryptography] RFC possible changes for Linux random device

[Jerry Leichter]

On Sep 14, 2014, at 2:06 PM, Bear <bear at sonic.net> wrote:
>> 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.  
> This seems like the sort of thing to test in very early boot.  
> Wake up, check a variable ARM-COUNTER from the disk, find it equal 
> to zero, write one to it, flush the disk buffer, attempt to 
> continue using the the counter.  If you don't crash, write a 
> zero back to ARM-COUNTER and remember (in some other bit) that 
> the counter is valid.  If you do crash, you wake up again in 
> a forced reboot, but this time you find ARM-COUNTER equal to 
> one - so you write a zero to it, remember (in your other bit) 
> that the counter is invalid, and never ever use the counter.  
> The result is that boxes where the instruction counter is 
> unimplemented have a slightly longer boot sequence, containing 
> one early crash-and-reboot.  It's ugly as sin, but I used to do 
> the same thing boot-testing for math coprocessors on 8088 boxes. 
"Disk"?  What is this "disk" you speak of?  :-)

ARM's are widely used in embedded applications which may have no need for persistent memory.  Your solution amounts to a configuration option, though one that the device can configure for itself.  Which is a great approach, for devices that actually have modifiable configurations!

                                                        -- Jerry