Thanks for weighing in, PaX Team. (And thank you for the awesome you
and spender do on kernel security!)
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? If so, which path seems
the best for us to move forward on?
