From: Matthew Wilcox <willy@infradead.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Balbir Singh <bsingharora@gmail.com>,
Mike Rapoport <rppt@linux.ibm.com>,
lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Subject: Re: [LSF/MM TOPIC] Address space isolation inside the kernel
Date: Sun, 17 Feb 2019 11:34:34 -0800 [thread overview]
Message-ID: <20190217193434.GQ12668@bombadil.infradead.org> (raw)
In-Reply-To: <1550334616.3131.10.camel@HansenPartnership.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:
> > 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
> 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.
next prev parent reply other threads:[~2019-02-17 19:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-07 7:24 [LSF/MM TOPIC] Address space isolation inside the kernel Mike Rapoport
2019-02-14 19:21 ` Kees Cook
[not found] ` <CA+VK+GOpjXQ2-CLZt6zrW6m-=WpWpvcrXGSJ-723tRDMeAeHmg@mail.gmail.com>
2019-02-16 11:13 ` Paul Turner
2019-04-25 20:47 ` Jonathan Adams
2019-04-25 21:56 ` James Bottomley
2019-04-25 22:25 ` Paul Turner
2019-04-25 22:31 ` [Lsf-pc] " Alexei Starovoitov
2019-04-25 22:40 ` Paul Turner
2019-02-16 12:19 ` Balbir Singh
2019-02-16 16:30 ` James Bottomley
2019-02-17 8:01 ` Balbir Singh
2019-02-17 16:43 ` James Bottomley
2019-02-17 19:34 ` Matthew Wilcox [this message]
2019-02-17 20:09 ` James Bottomley
2019-02-17 21:54 ` Balbir Singh
2019-02-17 22:01 ` Balbir Singh
2019-02-17 22:20 ` [Lsf-pc] " James Bottomley
2019-02-18 11:15 ` Balbir Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190217193434.GQ12668@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bsingharora@gmail.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=rppt@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).