Date: Wed, 14 May 2003 06:06:56 -0400 (EDT)
From: Ahmed Masud <masud@googgun.com>
To: Yoav Weiss <ml-lkml@unpatched.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: encrypted swap [was: The disappearing sys_call_table export.]
In-Reply-To: <Pine.LNX.4.44.0305140234110.32259-100000@marcellos.corky.net>
Message-ID: <Pine.LNX.4.33.0305140513460.10480-100000@marauder.googgun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1836
Lines: 50


On Wed, 14 May 2003, Yoav Weiss wrote:

> On Tue, 13 May 2003, Ahmed Masud wrote:
>
> Yes, it sounds like an interesting project.  Check out openbsd's paper
> about this: http://www.openbsd.org/papers/swapencrypt.ps

Thank you for this paper, it is a fun read. I do think however that a
few implementation differences should take place:

1. We should not enforce Rijndael as the only choice.

2. Every page should be encrypted iff it marked with some flag. This gives
a generic enough hook to create a swap_encrypt_policy type function to
determine whether it is desirable to encrypt a particular page or not.

2a. The above flag may also be set or cleared by the page-owner process on
a page-to-page basis (something a-kin to mlock()).

3. A slightly more sophisticated timeout framework should be created with
the ability to enforce expiry or request expiry extensions (upto some type
of a system hard limit?) on a per page.

Please comment.

This is an aside: should do we do anything about core dumps?

> Let me know when you get it rolling.  I'll try to help where I can.
> I just hope it has a chance to be included.

I will start looking at it seriously within next couple of days actually.
I looked at the swap stuff in mm code yesterday for the first time and it
seems (eeriely)  straightforward, and i know i am going to run into an
unseen brick wall :-).

I would suspect that somewhere between the io requst generated by
swap_readpage and swap_writepage cypto can be hooked in...  haven't yet
determined where/when the key generations should take place.

Cheers,

Ahmed Masud.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/