[Cryptography] RFC possible changes for Linux random device

Jerry Leichter leichter at lrw.com
Wed Sep 17 08:22:10 EDT 2014


On Sep 16, 2014, at 9:48 PM, Theodore Ts'o <tytso at mit.edu> wrote:
>> Also, do we want the kernel to mark pages that it puts entropy into as
>> "non-swappable" or "erase upon freeing", to keep the kernel from
>> making or retaining copies of the page that could be exploited by
>> adversaries?  If we're defining a new system interface, are there more
>> crypto/security/randomness issues we can address with it?
> 
> I see this as a completely orthogonal system interface.
In fact, it has nothing really to do with random values.  If such an interface were available, I'd want to put all "red" (sensitive, unencrypted) data in such pages.

>  We could
> arguement about adding a new madvise(2) flag that might have these
> semantics, but it's quite separate from random number generation.  It
> also has its own pitfalls; what happens if the user tries to mark all
> pages in this fashion.  Since the functionality is a superset of
> mlock(2)/mlockall(2), this can be quite problematic from a denial of
> service perspective.
We're talking much bigger changes here, but if we're going to think big:  Encrypted swap space, with *per process* encryption keys, would be almost as effective, without the potential for such a denial of service attack.  The per-process swap key would go into this kind of "crypto-secure" memory, but that would be a strictly limited bit of memory.

                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140917/3fd14a6e/attachment.bin>


More information about the cryptography mailing list