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

[Balbir Singh <bsingharora@gmail.com>]

On Sun, Feb 17, 2019 at 02:20:50PM -0800, James Bottomley wrote:
> On Mon, 2019-02-18 at 09:01 +1100, Balbir Singh wrote:
> > 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)
> 
> As I said before, it's about reducing the horizontal attack profile
> (HAP).  If the kernel were perfectly free from bugs and exploits,
> containment would be perfect and the HAP would be zero.  In the real
> world, where the kernel is trusted (it's your kernel) but potentially
> vulnerable (it's not free from possibly exploitable defects), the HAP
> is non-zero and the question becomes how do you prevent one tenant from
> exploiting a defect to interfere with or exfiltrate data from another
> tenant.
> 
> The idea behind page tagging is that modern techniqes (like ROP
> attacks) use existing code sequences within the kernel to perform the
> exploit so if all code sequences that map pages contain tag guards, the
> defences against one container accessing another pages remain in place
> even in the face of exploits.
>

Agreed, and I believe in defense in depth. I'd love to participate to
see what the final proposal looks like and what elements are used

Balbir Singh.