From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7FD1C07E85 for ; Fri, 7 Dec 2018 06:45:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7A79D20700 for ; Fri, 7 Dec 2018 06:45:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A79D20700 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-security-module-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725963AbeLGGpc (ORCPT ); Fri, 7 Dec 2018 01:45:32 -0500 Received: from mga06.intel.com ([134.134.136.31]:24641 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbeLGGpb (ORCPT ); Fri, 7 Dec 2018 01:45:31 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2018 22:45:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,324,1539673200"; d="scan'208";a="281670227" Received: from makoli-mobl1.amr.corp.intel.com (HELO localhost) ([10.254.201.154]) by orsmga005.jf.intel.com with ESMTP; 06 Dec 2018 22:45:25 -0800 Date: Thu, 6 Dec 2018 22:45:25 -0800 From: Jarkko Sakkinen To: "Huang, Kai" Cc: "tglx@linutronix.de" , "Schofield, Alison" , "dhowells@redhat.com" , "kirill.shutemov@linux.intel.com" , "peterz@infradead.org" , "jmorris@namei.org" , "keyrings@vger.kernel.org" , "linux-mm@kvack.org" , "linux-security-module@vger.kernel.org" , "Williams, Dan J" , "x86@kernel.org" , "hpa@zytor.com" , "mingo@redhat.com" , "luto@kernel.org" , "bp@alien8.de" , "Hansen, Dave" , "Nakajima, Jun" Subject: Re: [RFC v2 12/13] keys/mktme: Save MKTME data if kernel cmdline parameter allows Message-ID: <20181207064524.GC12969@intel.com> References: <1544148839.28511.28.camel@intel.com> <20181207063918.GB12969@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181207063918.GB12969@intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Thu, Dec 06, 2018 at 10:39:18PM -0800, Jarkko Sakkinen wrote: > 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: > > > MKTME (Multi-Key Total Memory Encryption) key payloads may include > > > data encryption keys, tweak keys, and additional entropy bits. These > > > are used to program the MKTME encryption hardware. By default, the > > > kernel destroys this payload data once the hardware is programmed. > > > > > > However, in order to fully support CPU Hotplug, saving the key data > > > becomes important. The MKTME Key Service cannot allow a new physical > > > package to come online unless it can program the new packages Key Table > > > to match the Key Tables of all existing physical packages. > > > > > > With CPU generated keys (a.k.a. random keys or ephemeral keys) the > > > saving of user key data is not an issue. The kernel and MKTME hardware > > > can generate strong encryption keys without recalling any user supplied > > > data. > > > > > > With USER directed keys (a.k.a. user type) saving the key programming > > > data (data and tweak key) becomes an issue. The data and tweak keys > > > are required to program those keys on a new physical package. > > > > > > In preparation for adding CPU hotplug support: > > > > > > 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. > > What is the application for saving the key anyway? > > With my current knowledge, I'm not even sure what is the application > for user provided keys. Ugh, right of course, you need to save the key in order to support hotplug. Cold boot is like the main security use case for this (probably would be worth to mention this in the documentation). /Jarkko