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

[Balbir Singh <bsingharora@gmail.com>]

On Sat, Feb 16, 2019 at 08:30:16AM -0800, James Bottomley wrote:
> 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/
> 

Thanks, so it's largely to prevent escaping the container namespace.
Since the topic thread was generic, I thought I'd ask

> 
> > > 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.
> 

Yep, understood

> > 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

I was wondering why keys are not sufficient? I know no one mentioned it,
but something I thought I'd bring it up.

> 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.
> 

Thanks for clarifying the scope

Balbir

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