Author: intrigeri Date: To: pageexec, spender CC: Tails developers Subject: Re: [Tails-dev] What is *not* erased (after shutdown) with
PAX_MEMORY_SANITIZE enabled?
Hi everybody!
Harlan Lieberman-Berg: > Thanks for weighing in, PaX Team. (And thank you for the awesome you
> and spender do on kernel security!)
+1 :)
> To summarize, it seems that we have a couple different options to choose
> from: > * Switch to a dedicated microkernel that does a memory wipe, and kexec
> into it. This could be something custom, or an enhancement of the
> preexisting solution. > Advantages are that it will (probably) give us the most clean wipe, as
> we can reduce the amount of space the kernel takes up and drop all
> functionality that's not absolutely needed. On the negative side, it
> will require continuing to support a separate codeline that's not
> going to be reused elsewhere, limiting testing and development
> effort. It also requires us to reenable kexec functionality, which
> exposes a risk of code injection unless we get signed kexec support. > * Rely on PAX_MEMORY_SANITIZE. This either takes the form of enhancing
> cleaning memory on shutdown, or kexec'ing into the same version of the
> kernel that's already running to rely on the buddy allocator clearing
> everything again. > Definite pro in that it reduces the amount of code maintained
> downstream by the Tails team to ~zero. Cons are increased reliance on
> more complex functionality in the kernel, and potentially relying on a
> somewhat undocumented and unplanned functionality in the kernel. (It
> seems unlikely that it'll change any time without us noticing, but
> it's possible.) > * Do it in userspace. Add functionality into the initramfs as
> necessary to wipe memory, and simply run an abbreviated shutdown. > This lets us not have to deal with the potential for kexec's attack
> surface, and is probably some medium amount of code between the above
> two options. Downside is that it potentially is less reliable in
> terms of clearing memory than the other options, and is probably
> slower time-to-first-bit-erased than the other options. > Does that seem like a fair summary to everyone?
It does seem like it to me.
> If so, which path seems the best for us to move forward on?
I prefer the two first options (mostly because the third one is
essentially what we're already doing, and are trying to
improve/replace).
Not sure which one of those two yet, but the next thing to do in both
cases is the same: make it possible to allow kexec without disabling
GRKERNSEC_KMEM entirely.
I don't know what configuration interface would be best: move kexec
disabling out of GRKERNSEC_KMEM, to another kernel build-time config
setting? Leave it as part of GRKERNSEC_KMEM, but add a sysctl to allow
re-enabling kexec at runtime? pipacs, spender: what do you think?
