Harlan Lieberman-Berg: > Currently, I have a mostly-working prototype, but I'm not particularly > happy with the performance; it needs some more attention.
Thanks for the update! >> However, we're looking into shipping a kernel with the grsecurity >> patch, and sadly, the GRKERNSEC_KMEM feature removes support for >> kexec. That feature is enabled in the Debian grsec kernels, and can't >> be disabled at runtime if compiled in. Any thoughts about this? > My prototype right now is itself a kernel that would need to be kexec'ed > into on shutdown, or started from grub. Instead of doing a kexec, you > could theoretically ACPI reboot the machine and work out a way of > signalling GRUB to boot the kernel, but that would cause you to pass > through the initialization procedures for the machine -- which is going > to be slow. Doesn't feel good enough, indeed. I seem to remember that EFI provides functionality to reboot directly into another OS without going through system initialization, but even if I was not dreaming 1. we still want to support legacy boot systems; 2. I doubt firmware & hardware vendors have bothered implementing and QA'ing it for the cheap laptop I can buy at the supermarket. > The security benefits to GRKERNSEC_KMEM seem pretty clear to me. I > suppose we could try to migrate the functionality we need into the > kernel itself and expose a custom syscall to trip the wipe off. That > would get around the kexec problem, but it would mean the prototype > would need to be completely redone (not a huge deal). This would at least be robust: the kernel knows how much it can wipe without killing its own ability to power off the machine afterwards. But maybe it's not worth the effort (that you evaluate as more than non-trivial below), because: > The separation in kernels was intentional; that way, we wouldn't > have to worry about what > structures might be keeping around infomation we wanted to wipe without > worrying about panic'ing the kernel we were running in. Agreed. Not having to worry about the memory that was in use by the previously kernel (e.g. tmpfs) is a key benefit of the kexec approach. While with the "add the functionality to the kernel itself" approach, the kernel needs to free the parts of its memory that can contain sensitive data (I suppose that's a long list and not always doable) before it can wipe free memory in a useful way. > We could also try and shim into the kernel the ability to kexec into > this wiping-kernel, […] I don't know how > much work that would be; my guess is a non-trivial amount, […] I doubt this has a chance to ever reach mainline, and I'm not looking forward to maintaining our own kernel, so unless it can be done as an out-of-tree module, I'd say let's not go this way. Now, taking a step back, I wonder: why does why GRKERNSEC_KMEM disables kexec? Is it because it's deemed dangerous in itself? Then perhaps it's be worth asking grsec people if they'd be open to controlling the kexec part with a more atomic setting. Or because it's broken by other protections brought by this feature? If it is so, how hard would it be to fix that? Two other random ideas, nothing too convincing but perhaps worth mentioning (it's not as if our current implementation was perfect, so let's aim for something that works with grsec even if it's not perfect either): * Extend PAX_MEMORY_WIPE to also erase the areas of the memory it currently leaves alone, and we care about, when they're freed; this buys much only a little, since it doesn't do anything about the memory still in use by the kernel; but perhaps it makes the result just as good as what we currently have, while improving robustness, UX and speed of emergency shutdown drastically. * Keep our current userspace approach, but run it using systemd + dracut's "go back to initramfs during shutdown" feature instead of kexec; we may erase a bit less RAM than currently (bonus from PAX_MEMORY_WIPE minus memory used by the kernel), but it would be compatible with kexec, and possibly more robust than the current initramfs-tools implementation. 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.