Hi!

quoted

quoted

If I have
different security designs for swap space and hibernate, then even a
chance of some swap leaking into this region is a problem.

Could you expand some more about the this part please?

Offline attacks (ie manipulating storage from underneath the machine)
are a major concern when enabling both swap and hibernate. But the
approach of adding integrity to mitigate offline attacks may differ
between swap and hibernate in the interest of performance. Swap for
instance essentially needs a per-page dictionary of hashes for
integrity, since pages can be added and removed arbitrarily. Hibernate
however just needs a single hash across the entire image to provide
integrity. If you have swap leaking onto a region where you don't have
integrity enabled (because say you handled integrity at the image
level for hibernate, and at the block layer for swap), your swap
integrity story is compromised.

If you want to encrypt/sign the hibernation, you likely should use
uswsusp, and that means you can store hibernation image where (and
how) you want it, without modifying kernel.

See kernel/power/user.c .

I don't think this digs the design hole deeper. Yes, the ship on this
design has long ago sailed. But if we ever did try to dig ourselves
out of the swap/hibernate hole by providing new APIs to handle them
separately, this flag would serve as a good cutover to divert out of
the swap code and into the new shiny hibernate-only code. The APIs are
never going to be totally disentangled, so a clean cutover opportunity
is the best one can hope for.

Is uswsusp the place that should provide clean cutover?

Anyway, I acked the patch before, but it looks like it was
mistake. I withdraw the ack.

Best regards,
								Pavel

-- 
http://www.livejournal.com/~pavelmachek