From: Alison Schofield <alison.schofield@intel.com>
To: "Huang, Kai" <kai.huang@intel.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"luto@kernel.org" <luto@kernel.org>,
"Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [RFC v2 12/13] keys/mktme: Save MKTME data if kernel cmdline parameter allows
Date: Thu, 6 Dec 2018 19:42:17 -0800 [thread overview]
Message-ID: <20181207034217.GA13388@alison-desk.jf.intel.com> (raw)
In-Reply-To: <1544148839.28511.28.camel@intel.com>
On Thu, Dec 06, 2018 at 06:14:03PM -0800, Huang, Kai wrote:
> On Mon, 2018-12-03 at 23:39 -0800, Alison Schofield wrote:
8< ------------
> > Add an 'mktme_vault' where key data is stored.
> >
> > Add 'mktme_savekeys' kernel command line parameter that directs
> > what key data can be stored. If it is not set, kernel does not
> > store users data key or tweak key.
> >
> > Add 'mktme_bitmap_user_type' to track when USER type keys are in
> > use. If no USER type keys are currently in use, a physical package
> > may be brought online, despite the absence of 'mktme_savekeys'.
>
> Overall, I am not sure whether saving key is good idea, since it breaks coldboot attack IMHO. We
> need to tradeoff between supporting CPU hotplug and security. I am not sure whether supporting CPU
> hotplug is that important, since for some other features such as SGX, we don't support CPU hotplug
> anyway.
Yes, saving the key data exposes it in a cold boot attack.
Here we have 2 conflicting requirements. Do not save the data and
support CPU hotplug. I don't think CPU hotplug support is budging!
If the risk of offering the mktme_savekeys option is too dangerous,
then we can't have user type keys.
Is mktme_savekeys options too risky to offer?
(That's not just a question for you Kai ;). I'll pursue too.)
>
> Alternatively, we can choose to use per-socket keyID, but not to program keyID globally across all
> sockets, so you don't have to save key while still supporting CPU hotplug.
An alternative, with a lot of impact to the core linux support for
MKTME. I don't think we need to go there. I'll leave this thought for
a Kirill or Dave to perhaps elaborate on.
Alison
>
> Thanks,
> -Kai
next prev parent reply other threads:[~2018-12-07 3:39 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 7:39 [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME) Alison Schofield
2018-12-04 7:39 ` [RFC v2 01/13] x86/mktme: Document the MKTME APIs Alison Schofield
2018-12-05 18:11 ` Andy Lutomirski
2018-12-05 19:22 ` Alison Schofield
2018-12-05 23:35 ` Andy Lutomirski
2018-12-06 8:04 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 02/13] mm: Generalize the mprotect implementation to support extensions Alison Schofield
2018-12-06 8:08 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 03/13] syscall/x86: Wire up a new system call for memory encryption keys Alison Schofield
2018-12-04 7:39 ` [RFC v2 04/13] x86/mm: Add helper functions for MKTME " Alison Schofield
2018-12-04 9:14 ` Peter Zijlstra
2018-12-05 5:49 ` Alison Schofield
2018-12-04 15:35 ` Andy Lutomirski
2018-12-05 5:52 ` Alison Schofield
2018-12-06 8:31 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 05/13] x86/mm: Set KeyIDs in encrypted VMAs Alison Schofield
2018-12-06 8:37 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 06/13] mm: Add the encrypt_mprotect() system call Alison Schofield
2018-12-06 8:38 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 07/13] x86/mm: Add helpers for reference counting encrypted VMAs Alison Schofield
2018-12-04 8:58 ` Peter Zijlstra
2018-12-05 5:28 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 08/13] mm: Use reference counting for " Alison Schofield
2018-12-04 7:39 ` [RFC v2 09/13] mm: Restrict memory encryption to anonymous VMA's Alison Schofield
2018-12-04 9:10 ` Peter Zijlstra
2018-12-05 5:30 ` Alison Schofield
2018-12-05 9:07 ` Peter Zijlstra
2018-12-04 7:39 ` [RFC v2 10/13] keys/mktme: Add the MKTME Key Service type for memory encryption Alison Schofield
2018-12-06 8:51 ` Sakkinen, Jarkko
2018-12-06 8:54 ` Sakkinen, Jarkko
2018-12-06 15:11 ` Dave Hansen
2018-12-06 22:56 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 11/13] keys/mktme: Program memory encryption keys on a system wide basis Alison Schofield
2018-12-04 9:21 ` Peter Zijlstra
2018-12-04 9:50 ` Kirill A. Shutemov
2018-12-05 5:44 ` Alison Schofield
2018-12-05 5:43 ` Alison Schofield
2018-12-05 9:10 ` Peter Zijlstra
2018-12-05 17:26 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 12/13] keys/mktme: Save MKTME data if kernel cmdline parameter allows Alison Schofield
2018-12-04 9:22 ` Peter Zijlstra
2018-12-07 2:14 ` Huang, Kai
2018-12-07 3:42 ` Alison Schofield [this message]
2018-12-07 6:39 ` Jarkko Sakkinen
2018-12-07 6:45 ` Jarkko Sakkinen
2018-12-07 11:47 ` Kirill A. Shutemov
2018-12-04 7:40 ` [RFC v2 13/13] keys/mktme: Support CPU Hotplug for MKTME keys Alison Schofield
2018-12-04 9:28 ` Peter Zijlstra
2018-12-05 5:32 ` Alison Schofield
2018-12-04 9:31 ` Peter Zijlstra
2018-12-05 5:36 ` Alison Schofield
2018-12-04 9:25 ` [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME) Peter Zijlstra
2018-12-04 9:46 ` Kirill A. Shutemov
2018-12-05 20:32 ` Sakkinen, Jarkko
2018-12-06 11:22 ` Kirill A. Shutemov
2018-12-06 14:59 ` Dave Hansen
2018-12-07 10:12 ` Huang, Kai
2018-12-06 21:23 ` Sakkinen, Jarkko
2018-12-07 11:54 ` Kirill A. Shutemov
2018-12-04 19:19 ` Andy Lutomirski
2018-12-04 20:00 ` Andy Lutomirski
2018-12-04 20:32 ` Dave Hansen
2018-12-05 22:19 ` Sakkinen, Jarkko
2018-12-07 2:05 ` Huang, Kai
2018-12-07 6:48 ` Jarkko Sakkinen
2018-12-07 11:57 ` Kirill A. Shutemov
2018-12-07 21:59 ` Sakkinen, Jarkko
2018-12-07 23:45 ` Sakkinen, Jarkko
2018-12-07 23:48 ` Andy Lutomirski
2018-12-08 1:33 ` Huang, Kai
2018-12-08 3:53 ` Sakkinen, Jarkko
2018-12-12 15:31 ` Sakkinen, Jarkko
2018-12-12 16:29 ` Andy Lutomirski
2018-12-12 16:43 ` Sakkinen, Jarkko
2018-12-12 23:27 ` Huang, Kai
2018-12-13 5:49 ` Sakkinen, Jarkko
2018-12-13 5:52 ` Sakkinen, Jarkko
2018-12-12 23:24 ` Huang, Kai
2018-12-07 23:35 ` Eric Rannaud
2018-12-05 23:49 ` Dave Hansen
2018-12-06 1:09 ` Andy Lutomirski
2018-12-06 1:25 ` Dan Williams
2018-12-06 15:39 ` Dave Hansen
2018-12-06 19:10 ` Andy Lutomirski
2018-12-06 19:31 ` Dave Hansen
2018-12-07 1:55 ` Huang, Kai
2018-12-07 4:23 ` Dave Hansen
2018-12-07 23:53 ` Andy Lutomirski
2018-12-08 1:11 ` Dave Hansen
2018-12-08 2:07 ` Huang, Kai
2018-12-05 20:30 ` Sakkinen, Jarkko
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=20181207034217.GA13388@alison-desk.jf.intel.com \
--to=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=jarkko.sakkinen@intel.com \
--cc=jmorris@namei.org \
--cc=jun.nakajima@intel.com \
--cc=kai.huang@intel.com \
--cc=keyrings@vger.kernel.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@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 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).