Re: [LSF/MM TOPIC] Address space isolation inside the kernel

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2019-02-16 at 23:19 +1100, Balbir Singh wrote:
> On Thu, Feb 07, 2019 at 09:24:22AM +0200, Mike Rapoport wrote:
> > (Joint proposal with James Bottomley)
> > 
> > Address space isolation has been used to protect the kernel from
> > the userspace and userspace programs from each other since the
> > invention of the virtual memory.
> > 
> > Assuming that kernel bugs and therefore vulnerabilities are
> > inevitable it might be worth isolating parts of the kernel to
> > minimize damage that these vulnerabilities can cause.
> > 
> 
> Is Address Space limited to user space and kernel space, where does
> the hypervisor fit into the picture?

It doesn't really.  The work is driven by the Nabla HAP measure

https://blog.hansenpartnership.com/measuring-the-horizontal-attack-profile-of-nabla-containers/

Although the results are spectacular (building a container that's
measurably more secure than a hypervisor based system), they come at
the price of emulating a lot of the kernel and thus damaging the
precise resource control advantage containers have.  The idea then is
to render parts of the kernel syscall interface safe enough that they
have a security profile equivalent to the emulated one and can thus be
called directly instead of being emulated, hoping to restore most of
the container resource management properties.

In theory, I suppose it would buy you protection from things like the
kata containers host breach:

https://nabla-containers.github.io/2018/11/28/fs/


> > There is already ongoing work in a similar direction, like XPFO [1]
> > and temporary mappings proposed for the kernel text poking [2].
> > 
> > We have several vague ideas how we can take this even further and
> > make different parts of kernel run in different address spaces:
> > * Remove most of the kernel mappings from the syscall entry and add
> > a
> >   trampoline when the syscall processing needs to call the "core
> >   kernel".
> > * Make the parts of the kernel that execute in a namespace use
> > their
> >   own mappings for the namespace private data
> 
> Is the key reason for removing mappings -- to remove the processor
> from speculating data/text from those mappings? SMAP/SMEP provides
> a level of isolation from access and execution

Not really, it's to reduce the exploitability of the code path and
limit the exposure of data which can be compromised when you're
exploited.

> For namespaces, does allocating the right memory protection key
> work? At some point we'll need to recycle the keys

I don't think anyone mentioned memory keys and namespaces ... I take it
you're thinking of SEV/MKTME?  The idea being to shield one container's
execution from another using memory encryption?  We've speculated it's
possible but the actual mechanism we were looking at is tagging pages
to namespaces (essentially using the mount namspace and tags on the
page cache) so the kernel would refuse to map a page into the wrong
namespace.  This approach doesn't seem to be as promising as the
separated address space one because the security properties are harder
to measure.

James


> It'll be an interesting discussion and I'd love to attend if invited
> 
> Balbir Singh.
>