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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 C874CC43140 for ; Thu, 21 Jun 2018 15:29:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 88154208B0 for ; Thu, 21 Jun 2018 15:29:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 88154208B0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933333AbeFUP3I (ORCPT ); Thu, 21 Jun 2018 11:29:08 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44742 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933114AbeFUP3G (ORCPT ); Thu, 21 Jun 2018 11:29:06 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C8BBC8A3AE; Thu, 21 Jun 2018 15:29:05 +0000 (UTC) Received: from hmswarspite.think-freely.org (ovpn-121-84.rdu2.redhat.com [10.10.121.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D3509200AA40; Thu, 21 Jun 2018 15:29:04 +0000 (UTC) Date: Thu, 21 Jun 2018 11:29:03 -0400 From: Neil Horman To: Nathaniel McCallum Cc: sean.j.christopherson@intel.com, jethro@fortanix.com, luto@kernel.org, jarkko.sakkinen@linux.intel.com, x86@kernel.org, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, intel-sgx-kernel-dev@lists.01.org, hpa@zytor.com, dvhart@infradead.org, tglx@linutronix.de, andy@infradead.org, Peter Jones Subject: Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave Message-ID: <20180621152903.GB1324@hmswarspite.think-freely.org> References: <20180611115255.GC22164@hmswarspite.think-freely.org> <20180612174535.GE19168@hmswarspite.think-freely.org> <20180620210158.GA24328@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 21 Jun 2018 15:29:05 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 21 Jun 2018 15:29:05 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'nhorman@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote: > On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson > wrote: > > > > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote: > > > On 2018-06-20 11:16, Jethro Beekman wrote: > > > > > This last bit is also repeated in different words in Table 35-2 and > > > > > Section 42.2.2. The MSRs are *not writable* before the write-lock bit > > > > > itself is locked. Meaning the MSRs are either locked with Intel's key > > > > > hash, or not locked at all. > > > > > > Actually, this might be a documentation bug. I have some test hardware and I > > > was able to configure the MSRs in the BIOS and then read the MSRs after boot > > > like this: > > > > > > MSR 0x3a 0x0000000000040005 > > > MSR 0x8c 0x20180620aaaaaaaa > > > MSR 0x8d 0x20180620bbbbbbbb > > > MSR 0x8e 0x20180620cccccccc > > > MSR 0x8f 0x20180620dddddddd > > > > > > Since this is not production hardware, it could also be a CPU bug of course. > > > > > > If it is indeed possible to configure AND lock the MSR values to non-Intel > > > values, I'm very much in favor of Nathaniels proposal to treat the launch > > > enclave like any other firmware blob. > > > > It's not a CPU or documentation bug (though the latter is arguable). > > SGX has an activation step that is triggered by doing a WRMSR(0x7a) > > with bit 0 set. Until SGX is activated, the SGX related bits in > > IA32_FEATURE_CONTROL cannot be set, i.e. SGX can't be enabled. But, > > the LE hash MSRs are fully writable prior to activation, e.g. to > > allow firmware to lock down the LE key with a non-Intel value. > > > > So yes, it's possible to lock the MSRs to a non-Intel value. The > > obvious caveat is that whatever blob is used to write the MSRs would > > need be executed prior to activation. > > This implies that it should be possible to create MSR activation (and > an embedded launch enclave?) entirely as a UEFI module. The kernel > would still get to manage who has access to /dev/sgx and other > important non-cryptographic policy details. Users would still be able > to control the cryptographic policy details (via BIOS Secure Boot > configuration that exists today). Distributions could still control > cryptographic policy details via signing of the UEFI module with their > own Secure Boot key (or using something like shim). The UEFI module > (and possibly the external launch enclave) could be distributed via > linux-firmware. > > Andy/Neil, does this work for you? > I need some time to digest it. Who in your mind is writing the UEFI module. Is that the firmware vendor or IHV? Neil > > As for the SDM, it's a documentation... omission? SGX activation > > is intentionally omitted from the SDM. The intended usage model is > > that firmware will always do the activation (if it wants SGX enabled), > > i.e. post-firmware software will only ever "see" SGX as disabled or > > in the fully activated state, and so the SDM doesn't describe SGX > > behavior prior to activation. I believe the activation process, or > > at least what is required from firmware, is documented in the BIOS > > writer's guide. > > > > > Jethro Beekman | Fortanix > > > > > > >