lkml.org 
[lkml]   [2009]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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.



    \
     
     \ /
      Last update: 2009-05-21 21:29    [W:0.023 / U:0.208 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site