Author: Harlan Lieberman-Berg Date: To: intrigeri CC: tails-dev Subject: Re: [Tails-dev] Memory Erasure Development
intrigeri <intrigeri@???> writes: > What's the current status?
Hi Intrigeri,
Currently, I have a mostly-working prototype, but I'm not particularly
happy with the performance; it needs some more attention. Most of the
problems are with the way I'm doing the memory mapping; I need to switch
to a moving window approach. That should help the performance
significantly.
I haven't worked on it for a month or two; when I ran into the
performance problems, I wasn't sure the value proposition was worth it
considering the "ugly-but-working" solution that is already in place.
If that system is starting to show problems, though...
> 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.
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). 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. Still, needs
must.
We could also try and shim into the kernel the ability to kexec into
this wiping-kernel, while trying to craft it in such a way that it
doesn't have as much of an attack surface as the GRKERNSEC_KMEM solution
is solving. (Probably, compiling the wiping-kernel directly into the
kernel itself, and only letting you kexec into that.) I don't know how
much work that would be; my guess is a non-trivial amount, though
probably not quite as much as trying to put the functionality into the
kernel proper.
