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? Cheers, -- intrigeri _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
