Hello,
My current understanding is that there is basically no protection in
Linux against the cold boot attack. This means that any encryption keys
either in kernel memory or in the page cache, as well as any other data
in the page cache, could be compromised by such an attack.
Of course, hibernating to encrypted swap protects against this risk, but
having to resort to this effectively limits the usefulness of
suspend-to-ram.
I propose the following solution:
Encrypt, in place, the page cache (except for the pages used by a
special userspace helper program) prior to entering S3. Upon resuming,
the userspace helper program somehow obtains the encryption key used to
encrypt the page cache (possibly by prompting the user for a password,
or reading the key off of some piece of removable hardware) and passes
it to the kernel to use to decrypt the page cache. Anything in the
kernel that stores encryption keys, such as dm-crypt, would copy its
keys to a special memory area that encrypted using the same key as the
page cache, prior to clearing the keys from their normal memory
locations.
This would presumably be much faster than hibernating, since hibernation
is typically severely limited by disk write speeds.
Specifically, I imagine the following sequence of steps would be taken:
1. Userspace helper is started.
2. Userspace helper specifies to kernel the encryption key to use for
the page cache.
3. Userspace helper tells kernel to enter S3.
4. Kernel uses freezer to freeze tasks (except userspace helper) exactly
as is done when hibernating and otherwise does what is needed to
ensure that nothing will try to access the page cache.
5. Kernel encrypts in place everything in the page cache except the
pages that are needed by the userspace helper program.
6. Dm-crypt keys and any other encryption keys in the kernel are copied
to a special memory area and encrypted using the same key as the page
cache, prior to being cleared from their original memory locations.
7. Kernel suspends devices and enters S3.
<Wakeup from S3>
8. Kernel resumes devices as is normally done when exiting S3. Tasks
except the userspace helper should still be frozen at this point.
9. Userspace helper obtains the encryption key (e.g. from the user or a
removable piece of hardware), and passes it to the kernel.
10. Kernel decrypts page cache and special key storage memory area.
11. Kernel tells dm-crypt and anything else that uses encryption keys in
the kernel to reinitialize themselves using the keys they stored in
the special key storage area.
12. Kernel unfreezes tasks.
13. Userspace helper exits.
Note: There is the additional issue of free pages. The kernel could
zero out these pages at the same time as it is encrypting the page
cache. The kernel could also just ensure all free pages are zeroed as
they become free.
This proposal doesn't address the issue of kernel memory that might
contain sensitive data (other than specifically the storage of
encryption keys in the kernel). Perhaps others can comment on where in
kernel memory additional sensitive data might be stored, and how it
might be encrypted (without crashing the system).
Perhaps anyone interested can comment on the viability of this proposal.
Ostensibly, the idea doesn't have anything to do with hibernation. It
does occur to me, though, that tuxonice may already support much of what
is needed to implement this proposal, and that it might be possible to
implement this with very little additional code added to tuxonice.
Handling dm-crypt keys and other sensitive data in kernel memory might
take more work (and in particular require some discussion about the
proper interface to use), but at least an initial proof-of-concept
implementation that only encrypts the page cache could probably be done
fairly easily.
If this were implemented (and it doesn't seem that it would take all
that much work), it would make Linux the only OS, as far as I know, that
is secure against cold boot attacks while in S3.
--
Jeremy Maitin-Shepard
Hi Jeremy.
I'd suggest emailing the Linux-PM list rather than tuxonice-devel.
TuxOnIce devel focuses on the out-of-vanilla suspend to disk
enhancements rather than on suspend to ram.
Regards,
Nigel
Nigel Cunningham <[email protected]> writes:
> Hi Jeremy.
> I'd suggest emailing the Linux-PM list rather than tuxonice-devel.
> TuxOnIce devel focuses on the out-of-vanilla suspend to disk
> enhancements rather than on suspend to ram.
The Linux-PM list is a good suggestion, but I specifically included
tuxonice because of the note at the bottom --- namely that I believe
that tuxonice in particular already includes support for much of what is
needed to implement the idea.
Specifically, suppose right at the stage in tuxonice hibernation when
the kernel as about to write the page cache pages to disk, it instead
just encrypts in place those pages, clears the encryption key, then
waits for the userspace helper to pass it back the key again to use to
decrypt the pages.
In fact it would seems that actually entering S3 is mostly irrelevant in
terms of the implementation.
Tuoxnice already has code to deal with interfacing with a userspace
helper that is kept unfrozen (and its pages handled specially) while
everything else is frozen and the page cache is overwritten, which is
precisely what is needed for this idea. In particular, it seems that an
implementation of the idea I proposed would look a lot like tuxonice
with a powerdown mode of entering S3, just that instead of writing the
page cache to disk, it is encrypted in place. I suppose it could well be that
all of the facilities used by tuxonice to do this are actually already
in the kernel, in which case it is indeed not relevant to tuxonice, but
it is not clear that the uswsusp infrastructure has everything that is
needed.
--
Jeremy Maitin-Shepard
Hi again.
Jeremy Maitin-Shepard wrote:
> Nigel Cunningham <[email protected]> writes:
>
>> Hi Jeremy.
>> I'd suggest emailing the Linux-PM list rather than tuxonice-devel.
>> TuxOnIce devel focuses on the out-of-vanilla suspend to disk
>> enhancements rather than on suspend to ram.
>
> The Linux-PM list is a good suggestion, but I specifically included
> tuxonice because of the note at the bottom --- namely that I believe
> that tuxonice in particular already includes support for much of what is
> needed to implement the idea.
Ah, sorry. I read too quickly.
> Specifically, suppose right at the stage in tuxonice hibernation when
> the kernel as about to write the page cache pages to disk, it instead
> just encrypts in place those pages, clears the encryption key, then
> waits for the userspace helper to pass it back the key again to use to
> decrypt the pages.
>
> In fact it would seems that actually entering S3 is mostly irrelevant in
> terms of the implementation.
>
> Tuoxnice already has code to deal with interfacing with a userspace
> helper that is kept unfrozen (and its pages handled specially) while
> everything else is frozen and the page cache is overwritten, which is
> precisely what is needed for this idea. In particular, it seems that an
> implementation of the idea I proposed would look a lot like tuxonice
> with a powerdown mode of entering S3, just that instead of writing the
> page cache to disk, it is encrypted in place. I suppose it could well be that
> all of the facilities used by tuxonice to do this are actually already
> in the kernel, in which case it is indeed not relevant to tuxonice, but
> it is not clear that the uswsusp infrastructure has everything that is
> needed.
You're absolutely right - TuxOnIce could be modified to do that, quite
easily.
As far as the possibility of using uswsusp goes, I'd like to get
Rafael's input there - he knows it much better than I do (explicitly
adding him to the ccs).
Regards,
Nigel
Hello Jeremy,
> Of course, hibernating to encrypted swap protects against this risk, but
> having to resort to this effectively limits the usefulness of
> suspend-to-ram.
I don't see how you come to this quick conclusion. If you are only
interested in suspend-to-ram, it is fairly easy set up dmcrypt with a
random key (determined at each boot) for your swap partition. The
performance issues are not noticeable but for extreme swap loads or
intensive parallel applications. In particular on a modern bi-core
processor you will never see a difference.
Such an approach has the advantage of crypting everything that
eventually is written to disk, in particular other privacy relevant
data such as memory used by editors or web browsers.
If you also want to do hibernation, the setup is a bit more complex,
but very much doable for an average linux user nowadays, AFAIKS
support exists in the major distributions. This works equally well
with both hibernation implementations. I use this since several years
now and I am much satisfied with the setup.
Best
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: Bat B - AlGorille :::::::::::::::::: fon +33 383593090 ::
:: campus scientifique, BP 239 :::::::: gsm +33 688495246 ::
:: 54506 Vand?uvre l?s Nancy, France :: fax +33 383278319 ::
On Wednesday 01 July 2009, Nigel Cunningham wrote:
> Hi again.
>
> Jeremy Maitin-Shepard wrote:
> > Nigel Cunningham <[email protected]> writes:
> >
> >> Hi Jeremy.
> >> I'd suggest emailing the Linux-PM list rather than tuxonice-devel.
> >> TuxOnIce devel focuses on the out-of-vanilla suspend to disk
> >> enhancements rather than on suspend to ram.
> >
> > The Linux-PM list is a good suggestion, but I specifically included
> > tuxonice because of the note at the bottom --- namely that I believe
> > that tuxonice in particular already includes support for much of what is
> > needed to implement the idea.
>
> Ah, sorry. I read too quickly.
>
> > Specifically, suppose right at the stage in tuxonice hibernation when
> > the kernel as about to write the page cache pages to disk, it instead
> > just encrypts in place those pages, clears the encryption key, then
> > waits for the userspace helper to pass it back the key again to use to
> > decrypt the pages.
> >
> > In fact it would seems that actually entering S3 is mostly irrelevant in
> > terms of the implementation.
> >
> > Tuoxnice already has code to deal with interfacing with a userspace
> > helper that is kept unfrozen (and its pages handled specially) while
> > everything else is frozen and the page cache is overwritten, which is
> > precisely what is needed for this idea. In particular, it seems that an
> > implementation of the idea I proposed would look a lot like tuxonice
> > with a powerdown mode of entering S3, just that instead of writing the
> > page cache to disk, it is encrypted in place. I suppose it could well be that
> > all of the facilities used by tuxonice to do this are actually already
> > in the kernel, in which case it is indeed not relevant to tuxonice, but
> > it is not clear that the uswsusp infrastructure has everything that is
> > needed.
>
> You're absolutely right - TuxOnIce could be modified to do that, quite
> easily.
>
> As far as the possibility of using uswsusp goes, I'd like to get
> Rafael's input there - he knows it much better than I do (explicitly
> adding him to the ccs).
No, the current mainline hibernation code can't be modified easily
to encrypt the page cache before suspending.
Also, I don't see much value in doing that before suspend to RAM, because
(1) passwords and encryption keys should be stored in mlocked memory and (2)
the encryption overhead (including measures to protect the encrypted page cache
from being corrupted) would hurt the speed of suspend to RAM and resume, which
is a very important thing.
Moreover, I don't really see how we can feed the decryption key to the
kernel during resume before the page cache can be accessed.
Best,
Rafael
Jens Gustedt <[email protected]> writes:
> Hello Jeremy,
>> Of course, hibernating to encrypted swap protects against this risk, but
>> having to resort to this effectively limits the usefulness of
>> suspend-to-ram.
[snip]
> If you also want to do hibernation, the setup is a bit more complex,
> but very much doable for an average linux user nowadays, AFAIKS
> support exists in the major distributions. This works equally well
> with both hibernation implementations. I use this since several years
> now and I am much satisfied with the setup.
The goal is to have a state in which sensitive data cannot be
compromised even if the machine is stolen. I am assuming that all of
the data on the hard drive is sensitive and that it is encrypted using
e.g. dm-crypt. Powering off the machine or hibernating to encrypted
swap indeed leaves the machine in such a state.
However, resuming from hibernation may take longer than desired. Thus
the goal of having some other state from which it is faster to resume
but the machine is still safe.
Entering S3 normally (which is actually basically equivalent to simply
leaving the machine on and doing nothing from a security perspective)
most certainly does not leave the machine in a safe state, since
sensitive data may still be in RAM, and it may be possible to read this
data using a cold boot attack.[1]
The idea I am proposing is to do something similar to what is done when
hibernating to encrypted swap: sensitive data in memory is encrypted in
place rather than encrypted as it is written to disk, which would
presumably be much faster than hibernating.
[1] http://en.wikipedia.org/wiki/Cold_boot_attack
--
Jeremy Maitin-Shepard
"Rafael J. Wysocki" <[email protected]> writes:
> [snip]
>> As far as the possibility of using uswsusp goes, I'd like to get
>> Rafael's input there - he knows it much better than I do (explicitly
>> adding him to the ccs).
> No, the current mainline hibernation code can't be modified easily
> to encrypt the page cache before suspending.
> Also, I don't see much value in doing that before suspend to RAM, because
> (1) passwords and encryption keys should be stored in mlocked memory
I do not have a complete understanding of linux memory management, but
couldn't such memory also be included in the encryption? The page cache
is presumably the bulk of memory, but I realize there are likely several
other places in memory that may contain sensitive data. However, it
would seem that encrypting these in place should, for the most part,
also be quite feasible.
> and (2)
> the encryption overhead (including measures to protect the encrypted page cache
> from being corrupted) would hurt the speed of suspend to RAM and resume, which
> is a very important thing.
I am not suggesting that it be done unconditionally. I am simply
suggesting that it be made available as an option, just as hibernating
to encrypted swap is an option, and using dm-crypt in general is an
option. Surely encrypting and decrypting would take additional time,
but it would also surely take far less time than hibernating and
resuming. On machines with hardware encryption support (such as the
future Intel Westmere processor), encrypting several gigabytes of memory
may not take very much time at all.
> Moreover, I don't really see how we can feed the decryption key to the
> kernel during resume before the page cache can be accessed.
My understanding is that this is something that is already done in
tuxonice. After the contents of the page cache are written to disk,
some of the page cache is overwritten with a copy of the rest of memory,
and the kernel continues to interact with the userspace UI program. I
would assume that this state is effectively equivalent to the state the
system would be in after encrypting the page cache. (Obviously the
memory needed by the userspace helper would have to be treated
specially.)
--
Jeremy Maitin-Shepard
On Wednesday 01 July 2009, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[email protected]> writes:
>
> > [snip]
>
> >> As far as the possibility of using uswsusp goes, I'd like to get
> >> Rafael's input there - he knows it much better than I do (explicitly
> >> adding him to the ccs).
>
> > No, the current mainline hibernation code can't be modified easily
> > to encrypt the page cache before suspending.
>
> > Also, I don't see much value in doing that before suspend to RAM, because
> > (1) passwords and encryption keys should be stored in mlocked memory
>
> I do not have a complete understanding of linux memory management, but
> couldn't such memory also be included in the encryption? The page cache
> is presumably the bulk of memory, but I realize there are likely several
> other places in memory that may contain sensitive data. However, it
> would seem that encrypting these in place should, for the most part,
> also be quite feasible.
What is the particular attach scenario you'd like to prevent
> > and (2)
> > the encryption overhead (including measures to protect the encrypted page cache
> > from being corrupted) would hurt the speed of suspend to RAM and resume, which
> > is a very important thing.
>
> I am not suggesting that it be done unconditionally. I am simply
> suggesting that it be made available as an option, just as hibernating
> to encrypted swap is an option, and using dm-crypt in general is an
> option. Surely encrypting and decrypting would take additional time,
> but it would also surely take far less time than hibernating and
> resuming. On machines with hardware encryption support (such as the
> future Intel Westmere processor), encrypting several gigabytes of memory
> may not take very much time at all.
>
> > Moreover, I don't really see how we can feed the decryption key to the
> > kernel during resume before the page cache can be accessed.
>
> My understanding is that this is something that is already done in
> tuxonice. After the contents of the page cache are written to disk,
> some of the page cache is overwritten with a copy of the rest of memory,
> and the kernel continues to interact with the userspace UI program. I
> would assume that this state is effectively equivalent to the state the
> system would be in after encrypting the page cache. (Obviously the
> memory needed by the userspace helper would have to be treated
> specially.)
There's one problem with this approach, which is that we're not sure if the
encrypted pages won't be written to by someone else. TuxOnIce makes the
assumption that it won't, but that has yet to be demonstrated.
Best,
Rafael
Hi.
Rafael J. Wysocki wrote:
> On Wednesday 01 July 2009, Jeremy Maitin-Shepard wrote:
>> "Rafael J. Wysocki" <[email protected]> writes:
>>
>>> [snip]
>>>> As far as the possibility of using uswsusp goes, I'd like to get
>>>> Rafael's input there - he knows it much better than I do (explicitly
>>>> adding him to the ccs).
>>> No, the current mainline hibernation code can't be modified easily
>>> to encrypt the page cache before suspending.
>>> Also, I don't see much value in doing that before suspend to RAM, because
>>> (1) passwords and encryption keys should be stored in mlocked memory
>> I do not have a complete understanding of linux memory management, but
>> couldn't such memory also be included in the encryption? The page cache
>> is presumably the bulk of memory, but I realize there are likely several
>> other places in memory that may contain sensitive data. However, it
>> would seem that encrypting these in place should, for the most part,
>> also be quite feasible.
>
> What is the particular attach scenario you'd like to prevent
>
>>> and (2)
>>> the encryption overhead (including measures to protect the encrypted page cache
>>> from being corrupted) would hurt the speed of suspend to RAM and resume, which
>>> is a very important thing.
>> I am not suggesting that it be done unconditionally. I am simply
>> suggesting that it be made available as an option, just as hibernating
>> to encrypted swap is an option, and using dm-crypt in general is an
>> option. Surely encrypting and decrypting would take additional time,
>> but it would also surely take far less time than hibernating and
>> resuming. On machines with hardware encryption support (such as the
>> future Intel Westmere processor), encrypting several gigabytes of memory
>> may not take very much time at all.
>>
>>> Moreover, I don't really see how we can feed the decryption key to the
>>> kernel during resume before the page cache can be accessed.
>> My understanding is that this is something that is already done in
>> tuxonice. After the contents of the page cache are written to disk,
>> some of the page cache is overwritten with a copy of the rest of memory,
>> and the kernel continues to interact with the userspace UI program. I
>> would assume that this state is effectively equivalent to the state the
>> system would be in after encrypting the page cache. (Obviously the
>> memory needed by the userspace helper would have to be treated
>> specially.)
>
> There's one problem with this approach, which is that we're not sure if the
> encrypted pages won't be written to by someone else. TuxOnIce makes the
> assumption that it won't, but that has yet to be demonstrated.
I can think of a couple of things that can be done here:
- Checksum the pages and verify the data hasn't changed.
- Unmap pages as they're compressed, so that any unexpected usage is caught.
Do you have any other ideas?
Regards,
Nigel
"Rafael J. Wysocki" <[email protected]> writes:
> [snip]
> What is the particular attach scenario you'd like to prevent
The standard cold boot attack, which basically allows the attacker to
obtain a copy of the data in RAM. System is powered on. RAM is
optionally cooled. RAM is then quickly removed from the original
machine, placed in another machine, and copied. See
http://en.wikipedia.org/wiki/Cold_boot_attack
The wikipedia page links to this Youtube video that nicely demonstrates
the attack:
http://www.youtube.com/watch?v=JDaicPIgn9U
The cooling helps to preserve the data for longer, but is not always
even necessary. Special hardware is not even needed. Depending on
whether the BIOS clears the memory during the POST, it might also be
possible to do the attack on the same machine (i.e. without having to
move the RAM into another machine) by rebooting it and booting from
e.g. a CD-ROM or USB drive.
> [snip]
> There's one problem with this approach, which is that we're not sure if the
> encrypted pages won't be written to by someone else. TuxOnIce makes the
> assumption that it won't, but that has yet to be demonstrated.
Yes, it certainly depends on that assumptions, but it is not necessarily
a problem that it does.
There are really two parts to that assumption:
1. Whether the current Linux kernel in a particular (or perhaps any)
configuration _does_ satisfy that assumption.
2. Whether Linux _should_ satisfy that assumption. This is important
because if something comes along later that violates the assumption,
it would be nice to be able to consider that something a bug and fix
it.
It is really the second part that is most important, though evaluating
the extent to which the first part holds would help in determining the
feasibility of the second part.
--
Jeremy Maitin-Shepard
Hi Jeremy,
Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[email protected]> writes:
>
>> What is the particular attach scenario you'd like to prevent
>
> The standard cold boot attack, which basically allows the attacker to
> obtain a copy of the data in RAM. System is powered on. RAM is
> optionally cooled. RAM is then quickly removed from the original
> machine, placed in another machine, and copied. See
> http://en.wikipedia.org/wiki/Cold_boot_attack
>
> The wikipedia page links to this Youtube video that nicely demonstrates
> the attack:
>
> http://www.youtube.com/watch?v=JDaicPIgn9U
>
> The cooling helps to preserve the data for longer, but is not always
> even necessary. Special hardware is not even needed. Depending on
> whether the BIOS clears the memory during the POST, it might also be
> possible to do the attack on the same machine (i.e. without having to
> move the RAM into another machine) by rebooting it and booting from
> e.g. a CD-ROM or USB drive.
>
This attack scenario essentially attacks the standard assumption that
memory contents is _immediately_ lost once power to the RAM is removed.
Essentially, the same problems arise whether the machine is suspended to
RAM or is just left on, with some screen saver or something similar in
place. So if the machine is snatched out of your hands it is still
running...
That's the reason why I personally prefer suspend-to-disk over
suspend-to-ram. Of course, if you have encryption in place, e.g. for you
home partition, it is necessary that the swap space is encrypted so that
the system state is protected during suspend-to-disk.
The approach to encrypt the memory contents during suspend-to-ram seems
to be a very fundamental change in the kernel, in order to protect
against a very specific attack. And unfortunately it helps only against
an cold-boot attack that happens during suspend-to-ram. It does not
protect against the attack taking place when the machine is just "on".
Just my 2c.
With best regards,
Ulrich
U Kuehn <[email protected]> writes:
> [snip]
> The approach to encrypt the memory contents during suspend-to-ram seems
> to be a very fundamental change in the kernel, in order to protect
> against a very specific attack.
As I have said, I believe that tuxonice already supports almost
everything that is needed to implement it, and that the changes would
not in fact have to be all that intrusive to the rest of the kernel.
It is a very specific attack in some sense, but it is also a very
general attack in that it affects practically every computer out there.
> And unfortunately it helps only against an cold-boot attack that
> happens during suspend-to-ram. It does not protect against the attack
> taking place when the machine is just "on".
Naturally the protection is only effective when it is actually engaged.
However, I think that the cases in which a machine is susceptible to
being stolen or tampered often correspond to cases in which it makes
sense to have it suspended. For a laptop, for instance, the highest
risk is likely when the machine is left unattended or in transit. In
either case, it would likely be reasonable to have the machine
suspended. Obviously the protection would not help you if you wish to
leave the machine unattended while it completes some computational task.
Nonetheless, I believe the level of protection offered would still be
very useful to many people, myself included.
--
Jeremy Maitin-Shepard
On Thursday 02 July 2009, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[email protected]> writes:
>
> > [snip]
>
> > What is the particular attach scenario you'd like to prevent
>
> The standard cold boot attack, which basically allows the attacker to
> obtain a copy of the data in RAM. System is powered on. RAM is
> optionally cooled. RAM is then quickly removed from the original
> machine, placed in another machine, and copied. See
> http://en.wikipedia.org/wiki/Cold_boot_attack
>
> The wikipedia page links to this Youtube video that nicely demonstrates
> the attack:
>
> http://www.youtube.com/watch?v=JDaicPIgn9U
>
> The cooling helps to preserve the data for longer, but is not always
> even necessary. Special hardware is not even needed. Depending on
> whether the BIOS clears the memory during the POST, it might also be
> possible to do the attack on the same machine (i.e. without having to
> move the RAM into another machine) by rebooting it and booting from
> e.g. a CD-ROM or USB drive.
>
> > [snip]
>
> > There's one problem with this approach, which is that we're not sure if the
> > encrypted pages won't be written to by someone else. TuxOnIce makes the
> > assumption that it won't, but that has yet to be demonstrated.
>
> Yes, it certainly depends on that assumptions, but it is not necessarily
> a problem that it does.
>
> There are really two parts to that assumption:
>
> 1. Whether the current Linux kernel in a particular (or perhaps any)
> configuration _does_ satisfy that assumption.
This hasn't been verified.
> 2. Whether Linux _should_ satisfy that assumption. This is important
> because if something comes along later that violates the assumption,
> it would be nice to be able to consider that something a bug and fix
> it.
This hasn't even been discussed.
> It is really the second part that is most important, though evaluating
> the extent to which the first part holds would help in determining the
> feasibility of the second part.
That depends on whether or not the TuxOnIce approach to hibernation is
implemented in the mainline kernel. I'm still going to work on this, although
at the moment I'm working on some things that I regard as more urgent, but
since it's going to affect multiple subsystems, we'll need to discuss this.
The timing is not particularly good for that, though.
Best,
Rafael
> > Specifically, suppose right at the stage in tuxonice hibernation when
> > the kernel as about to write the page cache pages to disk, it instead
> > just encrypts in place those pages, clears the encryption key, then
> > waits for the userspace helper to pass it back the key again to use to
> > decrypt the pages.
> >
> > In fact it would seems that actually entering S3 is mostly irrelevant in
> > terms of the implementation.
> >
> > Tuoxnice already has code to deal with interfacing with a userspace
> > helper that is kept unfrozen (and its pages handled specially) while
> > everything else is frozen and the page cache is overwritten, which is
> > precisely what is needed for this idea. In particular, it seems that an
> > implementation of the idea I proposed would look a lot like tuxonice
> > with a powerdown mode of entering S3, just that instead of writing the
> > page cache to disk, it is encrypted in place. I suppose it could well be that
> > all of the facilities used by tuxonice to do this are actually already
> > in the kernel, in which case it is indeed not relevant to tuxonice, but
> > it is not clear that the uswsusp infrastructure has everything that is
> > needed.
>
> You're absolutely right - TuxOnIce could be modified to do that, quite
> easily.
>
> As far as the possibility of using uswsusp goes, I'd like to get
> Rafael's input there - he knows it much better than I do (explicitly
> adding him to the ccs).
I believe uswsusp could be used rather easily. Just modify s2disk to
encrypt image in ram without writing it out, then decrypt it from ram
and resume... it should be interesting hack.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek <[email protected]> writes:
[snip]
> I believe uswsusp could be used rather easily. Just modify s2disk to
> encrypt image in ram without writing it out, then decrypt it from ram
> and resume... it should be interesting hack.
As far as I understand, that would be completely useless since the image
that would be encrypted would just be a copy of what would still remain
in memory.
--
Jeremy Maitin-Shepard
On Wed 2009-07-08 03:47:53, Jeremy Maitin-Shepard wrote:
> Pavel Machek <[email protected]> writes:
>
> [snip]
>
> > I believe uswsusp could be used rather easily. Just modify s2disk to
> > encrypt image in ram without writing it out, then decrypt it from ram
> > and resume... it should be interesting hack.
>
> As far as I understand, that would be completely useless since the image
> that would be encrypted would just be a copy of what would still remain
> in memory.
Yes... so next step would be kernel call that would erase all the
pagecache and anonymous pages. You would still leave some data in
kernel structures, but that would be quite hard to fix.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek <[email protected]> writes:
> On Wed 2009-07-08 03:47:53, Jeremy Maitin-Shepard wrote:
>> Pavel Machek <[email protected]> writes:
>>
>> [snip]
>>
>> > I believe uswsusp could be used rather easily. Just modify s2disk to
>> > encrypt image in ram without writing it out, then decrypt it from ram
>> > and resume... it should be interesting hack.
>>
>> As far as I understand, that would be completely useless since the image
>> that would be encrypted would just be a copy of what would still remain
>> in memory.
> Yes... so next step would be kernel call that would erase all the
> pagecache and anonymous pages. You would still leave some data in
> kernel structures, but that would be quite hard to fix.
Okay. (This does still require the same assumption as TuxOnIce
regarding the page cache, though.)
--
Jeremy Maitin-Shepard
On Wed 2009-07-08 04:09:41, Jeremy Maitin-Shepard wrote:
> Pavel Machek <[email protected]> writes:
>
> > On Wed 2009-07-08 03:47:53, Jeremy Maitin-Shepard wrote:
> >> Pavel Machek <[email protected]> writes:
> >>
> >> [snip]
> >>
> >> > I believe uswsusp could be used rather easily. Just modify s2disk to
> >> > encrypt image in ram without writing it out, then decrypt it from ram
> >> > and resume... it should be interesting hack.
> >>
> >> As far as I understand, that would be completely useless since the image
> >> that would be encrypted would just be a copy of what would still remain
> >> in memory.
>
> > Yes... so next step would be kernel call that would erase all the
> > pagecache and anonymous pages. You would still leave some data in
> > kernel structures, but that would be quite hard to fix.
>
> Okay. (This does still require the same assumption as TuxOnIce
> regarding the page cache, though.)
(Not sure; clearing the page cache could be done atomically, from
interrupts disabled. But I'm no mm expert.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek <[email protected]> writes:
> On Wed 2009-07-08 04:09:41, Jeremy Maitin-Shepard wrote:
>> Pavel Machek <[email protected]> writes:
>>
>> > On Wed 2009-07-08 03:47:53, Jeremy Maitin-Shepard wrote:
>> >> Pavel Machek <[email protected]> writes:
>> >>
>> >> [snip]
>> >>
>> >> > I believe uswsusp could be used rather easily. Just modify s2disk to
>> >> > encrypt image in ram without writing it out, then decrypt it from ram
>> >> > and resume... it should be interesting hack.
>> >>
>> >> As far as I understand, that would be completely useless since the image
>> >> that would be encrypted would just be a copy of what would still remain
>> >> in memory.
>>
>> > Yes... so next step would be kernel call that would erase all the
>> > pagecache and anonymous pages. You would still leave some data in
>> > kernel structures, but that would be quite hard to fix.
>>
>> Okay. (This does still require the same assumption as TuxOnIce
>> regarding the page cache, though.)
> (Not sure; clearing the page cache could be done atomically, from
> interrupts disabled. But I'm no mm expert.)
But surely it wouldn't work to leave interrupts disabled after that
until the page cache is restored. After the page cache (and other
sensitive memory) is encrypted, after possibly entering and resuming
from S3, the page cache needs to be decrypted. Userspace will be doing
the decryption if a uswsusp-like model is being used, and even if the
decryption is done in the kernel, userspace needs to provide the
encryption key to the kernel. Even disregarding the issue of running
userspace with interrupts disabled, which I assume might have problems,
userspace would likely need to talk to some of the devices in order to
obtain the encryption key from the user.
--
Jeremy Maitin-Shepard
On Fri 2009-07-10 00:05:23, Jeremy Maitin-Shepard wrote:
> Pavel Machek <[email protected]> writes:
>
> > On Wed 2009-07-08 04:09:41, Jeremy Maitin-Shepard wrote:
> >> Pavel Machek <[email protected]> writes:
> >>
> >> > On Wed 2009-07-08 03:47:53, Jeremy Maitin-Shepard wrote:
> >> >> Pavel Machek <[email protected]> writes:
> >> >>
> >> >> [snip]
> >> >>
> >> >> > I believe uswsusp could be used rather easily. Just modify s2disk to
> >> >> > encrypt image in ram without writing it out, then decrypt it from ram
> >> >> > and resume... it should be interesting hack.
> >> >>
> >> >> As far as I understand, that would be completely useless since the image
> >> >> that would be encrypted would just be a copy of what would still remain
> >> >> in memory.
> >>
> >> > Yes... so next step would be kernel call that would erase all the
> >> > pagecache and anonymous pages. You would still leave some data in
> >> > kernel structures, but that would be quite hard to fix.
> >>
> >> Okay. (This does still require the same assumption as TuxOnIce
> >> regarding the page cache, though.)
>
> > (Not sure; clearing the page cache could be done atomically, from
> > interrupts disabled. But I'm no mm expert.)
>
> But surely it wouldn't work to leave interrupts disabled after that
> until the page cache is restored. After the page cache (and other
> sensitive memory) is encrypted, after possibly entering and resuming
> from S3, the page cache needs to be decrypted. Userspace will be
> doing
I see no need for that. You'd do something like 'kill -9 -1; echo 3 >
drop_caches' after snapshot, then scrub free ram. At that point you
should have no sensitive data in the memory, and encrypted image you
can restore.
(Now, kill -9 -1 with frozen tasks may be tricky to implement....)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html