Messages in this thread | | | Date | Thu, 21 May 2009 20:26:28 +0100 | From | Alan Cox <> | Subject | Re: [patch 0/5] Support for sanitization flag in low-level page allocator |
| |
> You don't always know this at page free time.
You do at buffer free time.
> I could see the PG_sensitive flag being used from > userspace through mmap or madvise flags. This way > the sensitive memory from a program like gpg would > be cleaned, even if gpg died in a segfault accident.
Still doesn't need a page flag - that is a vma flag which is far cheaper. Also means you can get rid of the stupid mlock() misuse by things like GPG to work around OS weaknesses by crypting the page if it hits disk/swap/whatever.
> I could also imagine the suspend-to-disk code skipping > PG_sensitive pages when storing data to disk, and > replacing it with some magic signature so programs > that use special PG_sensitive buffers can know that > their crypto key disappeared after a restore.
Its irrelevant in the simple S2D case. I just patch other bits of the suspend image to mail me the new key later. The right answer is crypted swap combined with a hard disk password and thus a crypted and locked suspend image. Playing the "I must not miss any page which might be sensitive even compiler stack copies and library buffers I don't know about" game is not going to build you a secure system - its simply *lousy* engineering and design.
Basically though - loss of physical control means you have to assue the recovered system is compromised. I doubt even TC is going to manage to spot firmware compromises on your CD-ROM drive, which thanks to the film industry creating a demand for altered firmware is a well understood field...
The cost of doing crypto on suspend to disk relative to media speed is basically irrelevant on a PC today. In the S2R case you might want to crypt those pages against an electronic pure read of RAM type attack but this is getting into serious spook territory.
| |