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.
