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

[Balbir Singh <bsingharora@gmail.com>]

On Sun, Feb 17, 2019 at 12:09:06PM -0800, James Bottomley wrote:
> On Sun, 2019-02-17 at 11:34 -0800, Matthew Wilcox wrote:
> > 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:
> > > > 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?
> > 
> > I thought he meant Protection Keys
> > https://en.wikipedia.org/wiki/Memory_protection#Protection_keys
> 
> Really?  I wasn't really considering that mainly because in parisc we
> use them to implement no execute, so they'd have to be repurposed.
> 
> > > 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.
> > 
> > What do you mean by "tags on the pages cache"?  Is that different
> > from the radix tree tags (now renamed to XArray marks), which are
> > search keys.
> 
> Tagging the page cache to namespaces means having a set of mount
> namespaces per page in the page cache and not allowing placing the page
> into a VMA unless the owning task's nsproxy is one of the tagged mount
> namespaces.  The idea was to introduce kernel supported fencing between
> containers, particularly if they were handling sensitive data, so that
> if a container used an exploit to map another container's page, the
> mapping would fail.  However, since sensitive data should be on an
> encrypted filesystem, it looks like SEV/MKTME coupled with file based
> encryption might provide a better mechanism.
>

Splitting out this point to a different email, I think being able to
tag page cache is quite interesting and in the long run might help
us to get things like mincore() right across shared boundaries.

But any fencing will come in the way of sharing and density of containers.
I still don't see how a container can map page cache it does not have
right permissions to/for? In an ideal world any writable pages (sensitive)
should ideally go to the writable bits of the union mount filesystem which is
private to the container (but I could be making up things without
trying them out)

Balbir Singh.