Re: [Tails-dev] What is *not* erased (after shutdown) with P…

Delete this message

Reply to this message
Autore: PaX Team
Data:  
To: The Tails public development discussion list, Andrew Gallagher
CC: spender
Oggetto: Re: [Tails-dev] What is *not* erased (after shutdown) with PAX_MEMORY_SANITIZE enabled?
On 4 Jan 2017 at 1:17, Andrew Gallagher wrote:

> > On 3 Jan 2017, at 21:40, PaX Team <pageexec@???> wrote:
> >
> > in other words, if you were to kexec into a SANITIZE enabled kernel,
> > you'd get your memory clearing for free automatically, earlier than
> > any initramfs would execute even and it'd cover most kernel memory
> > that the kernel ever cares about (or cared in its previous incarnation
> > at least).
> >
> > now this brings us to the other topic you raised about grsecurity's
> > KMEM hardening. technically it's not incompatible with kexec, so you
> > can re-enable kexec, however note that until some signed kexec mechanism
> > enters the kernel, it carries a risk of executing potentially malicious
> > kernels (but maybe that's not a problem in your use cases). perhaps
> > embedding or loading the kexec kernel from initramfs would get around
> > those concerns for good.
>
> Can you kexec from a running kernel into itself?


if by 'itself' you mean the kernel image running in memory then the
answer is 'no', or at least 'not without further surgery'.

such surgery would involve among others:
  - not freeing the init code/data on boot
  - restoring the load-time content of writable kernel sections
  - simulating the early boot environment (memory map, firmware and/or
    boot loader provided data, etc)


this is feasible but i'm not sure if it's worth the effort when you can
just kexec a kernel, even the same one (loaded separately into memory
of course). note also that i'm not really a kexec guy, so you should
probably talk to the kernel maintainers as well...