From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: linux-security-module@vger.kernel.org
Subject: Re: [RFC] KEYS: inject an MKTME specific safety check in the keyctl revoke path
Date: Fri, 31 Aug 2018 11:06:43 +0000 [thread overview]
Message-ID: <20180831110643.GC9346@linux.intel.com> (raw)
In-Reply-To: <20180831110543.GB9346@linux.intel.com>
On Fri, Aug 31, 2018 at 02:05:43PM +0300, Jarkko Sakkinen wrote:
> On Mon, Aug 13, 2018 at 07:05:38PM -0700, Alison Schofield wrote:
> > This RFC is asking for feedback on a problem I'm running into using
> > the Kernel Key Service for MKTME (MultiKey Total Memory Encryption).
> >
> > I previously posted an RFC with the proposal to create a new key type
> > "mktme" to support MKTME (Multi-Key Total Memory Encryption).
> > https://www.spinics.net/lists/keyrings/msg03702.html
> >
> > The MKTME key service maps userspace keys to hardware keyids. Those
> > keys are used in a new system call that encrypts memory. The keys
> > need to be tightly controlled. One example is that userspace keys
> > should not be revoked while the hardware keyid slot is still in use.
>
> What is the new syscall? Can you point to a description?
>
> >
> > The KEY_FLAG_KEEP bit offers good control. The mktme service uses that
> > bit to prevent userspace keys from disappearing without the service
> > being notified.
> >
> > Problem is that we need a safe and synchronous way to revoke keys. The
> > way .revoke methods function now, the key service type is called late
> > in the revoke process. The mktme key service has no means to reject the
> > request. So, even if the mktme service sanity checks the request in its
> > .revoke method, it's too late to do anything about it.
>
> I have trouble understanding the problem. I'm just seeing what you need
> but I don't know why you need it...
Ignore this. I got the problem once I looked at the :-) Do not ignore
other comments.
/Jarkko
WARNING: multiple messages have this Message-ID (diff)
From: jarkko.sakkinen@linux.intel.com (Jarkko Sakkinen)
To: linux-security-module@vger.kernel.org
Subject: [RFC] KEYS: inject an MKTME specific safety check in the keyctl revoke path
Date: Fri, 31 Aug 2018 14:06:43 +0300 [thread overview]
Message-ID: <20180831110643.GC9346@linux.intel.com> (raw)
In-Reply-To: <20180831110543.GB9346@linux.intel.com>
On Fri, Aug 31, 2018 at 02:05:43PM +0300, Jarkko Sakkinen wrote:
> On Mon, Aug 13, 2018 at 07:05:38PM -0700, Alison Schofield wrote:
> > This RFC is asking for feedback on a problem I'm running into using
> > the Kernel Key Service for MKTME (MultiKey Total Memory Encryption).
> >
> > I previously posted an RFC with the proposal to create a new key type
> > "mktme" to support MKTME (Multi-Key Total Memory Encryption).
> > https://www.spinics.net/lists/keyrings/msg03702.html
> >
> > The MKTME key service maps userspace keys to hardware keyids. Those
> > keys are used in a new system call that encrypts memory. The keys
> > need to be tightly controlled. One example is that userspace keys
> > should not be revoked while the hardware keyid slot is still in use.
>
> What is the new syscall? Can you point to a description?
>
> >
> > The KEY_FLAG_KEEP bit offers good control. The mktme service uses that
> > bit to prevent userspace keys from disappearing without the service
> > being notified.
> >
> > Problem is that we need a safe and synchronous way to revoke keys. The
> > way .revoke methods function now, the key service type is called late
> > in the revoke process. The mktme key service has no means to reject the
> > request. So, even if the mktme service sanity checks the request in its
> > .revoke method, it's too late to do anything about it.
>
> I have trouble understanding the problem. I'm just seeing what you need
> but I don't know why you need it...
Ignore this. I got the problem once I looked at the :-) Do not ignore
other comments.
/Jarkko
next prev parent reply other threads:[~2018-08-31 11:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-14 2:05 [RFC] KEYS: inject an MKTME specific safety check in the keyctl revoke path Alison Schofield
2018-08-14 2:05 ` Alison Schofield
2018-08-17 2:49 ` Huang, Kai
2018-08-17 2:49 ` Huang, Kai
2018-08-29 0:33 ` Alison Schofield
2018-08-29 0:33 ` Alison Schofield
2018-08-29 0:36 ` Alison Schofield
2018-08-29 0:36 ` Alison Schofield
2018-08-31 11:05 ` Jarkko Sakkinen
2018-08-31 11:05 ` Jarkko Sakkinen
2018-08-31 11:06 ` Jarkko Sakkinen [this message]
2018-08-31 11:06 ` Jarkko Sakkinen
2018-08-31 16:55 ` Alison Schofield
2018-08-31 16:55 ` Alison Schofield
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=20180831110643.GC9346@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=linux-security-module@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.