On Wed, 14 May 2003, Ahmed Masud wrote:
> 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.
I agree.
>
> 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.
Good idea. Of course, a policy that only encrypts the secret stuff may
have an impact on security, but it makes sense to let the user decide on a
policy.
>
> 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()).
And just like mlock(), only root will be able to call it.
>
> 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.
>
Why is this one needed ?
> This is an aside: should do we do anything about core dumps?
>
Thats a good question. I see three options:
1. Dump the core plaintext. (sucks but convenient for users).
2. In the core, zero the pages that would be encrypted when swapped out.
On some policies where only things like keys are encrypted, the core
will be usable. On others it won't. (Not sure its really an option).
3. If the core contains pages that should be encrypted, dump it encrypted
with some system-wide (or per-uid) key generated on the first core
dump. The key will be available to the user via some /proc interface.
Its up to the user to be smart and take the core to another host and
decrypt_core(1) it there (or just decrypt_core(1) it to an encrypted
filesystem). In any case, the decrypted core or the system-wide key
are never written to disk.
4. Refuse to dump core of a process that has pages that should be
encrypted.
Do you see more options ?
Anyway, it should probably be policy controlled.
> 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'm not familiar with this core either and somehow got the same feeling
when I looked into it :)
>
> 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.
Probably at process initialization during fork. The key must be ready
before the process gets its first chance to allocated pages that may be
swapped out.
>
> Cheers,
>
> Ahmed Masud.
>
>
Bye,
Yoav Weiss
-
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/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:51 EST