Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1984814imm; Thu, 21 Jun 2018 05:34:00 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIzQs/8cb95VmGNEUOs6QBO3+XBNFWDI/1ukFPxYpkX0tGXOBa777CuTFAGIIoA88zQQCWZ X-Received: by 2002:a65:49cb:: with SMTP id t11-v6mr22188731pgs.218.1529584440325; Thu, 21 Jun 2018 05:34:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529584440; cv=none; d=google.com; s=arc-20160816; b=fm8O5SEvMrQ9lkRGosCqjT4LEQyH6CzWgpTf6CfYTVpoyqXBlNaep3jnKECxoq07vr fFlIvwgjTlIfrUhlotwbF782Z4+/OyUuHuWBFczgKoFDdipxVqPuKAO8/pEO9106dyXK GRcjXDvFi7IfWE/ytuuxjxbth1mfa4nekh4RopnPMxsdUqKdq0BZW1SPwngUvGd3h3ac /zZrwlGzDr+fXbSy3I+WA2QtjG+jsqYQuKmuG1Ij3WGMTsV8XUG5L+sVZgk/VUsTm/Zo NuXriNUIwYBDAyM0flo97NsvpeerDOTYz4dEAbIJhCMQNsuS0InKAkjXJzHxIgcsPPBw iJpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:arc-authentication-results; bh=+ry/ot02F4lh2u4YOC2oVa9Z1CH8DiebNfrfiM1eyzM=; b=tAqLElwaIBn2Onu3ttYowU+eM2GPXNfSXqpEIGVzSieYvYSyZKh8c3dg4AuwOALKMN nxKEGnLNe/B7Nin2W66ND7/zJOuE79ks26Mqx8FDx8h8MQOmdrqx9Pgk1i8VXL8VDV0w 7sosXr241wgiB6EOEtlDm+c65P+LzL10ft7yj4OfSvfzmWtT2riyUx/6TSpyLCed5o5D O/ZIfXNv3bYOfJtVpeNvog3lIzgk9pa77kvRO+lJXMkqJNsMDPZLrE7os8HaAILIA4mA gVLEk49QIhccbQxFV9OxkzoB1pbAMI0vaUlkAK4lcQrb+sLv2FYMV7FU4LlcRWiLDa/W vwwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w10-v6si4885478ply.482.2018.06.21.05.33.45; Thu, 21 Jun 2018 05:34:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933713AbeFUMcm (ORCPT + 99 others); Thu, 21 Jun 2018 08:32:42 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:45136 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933675AbeFUMci (ORCPT ); Thu, 21 Jun 2018 08:32:38 -0400 Received: by mail-oi0-f67.google.com with SMTP id 188-v6so2725747oid.12 for ; Thu, 21 Jun 2018 05:32:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+ry/ot02F4lh2u4YOC2oVa9Z1CH8DiebNfrfiM1eyzM=; b=LrVreY+Jm7uHdFmBWDTAcWxDWfRylOPXZq+gs8iZg4n49T+/JReZC+HFoS8w8+UgTv 0OSbAXTPyM92RI4YgrbR+Naia73HMtd0vTKW7Av4LwtvlZLabzZnVQSbsKnDJUwOs/Cf q0RV+9mn5FOauYo7s7iNpuhSw64Eicbn0BDo8kVaq5WYYfadnY2KqT9xCFIF7hELV8wi wUWsUtazCYWX0Y9I43V6QApvZUgySptrMjaA0OWDMGWxSxNqfOGmf5VXg2sDvBXtm+pB jS/S6DFIX5HjC0PTqowRzAWHUpGOk2frIy2n7Lhu//rP/8OL58oG4T4xci+JyJ38/Hcf V/fQ== X-Gm-Message-State: APt69E2P3KvLPaNFHoJ1KSxf8vzio+zxWkY3nvhbrRIThJmjUs/x/Td/ 0uwCQcL0j7dx3bByd8OScgLbOggNuN6Y0aXQMOa4tA== X-Received: by 2002:aca:e7c8:: with SMTP id e191-v6mr13712162oih.202.1529584357604; Thu, 21 Jun 2018 05:32:37 -0700 (PDT) MIME-Version: 1.0 References: <20180608171216.26521-14-jarkko.sakkinen@linux.intel.com> <20180611115255.GC22164@hmswarspite.think-freely.org> <20180612174535.GE19168@hmswarspite.think-freely.org> <20180620210158.GA24328@linux.intel.com> In-Reply-To: <20180620210158.GA24328@linux.intel.com> From: Nathaniel McCallum Date: Thu, 21 Jun 2018 08:32:25 -0400 Message-ID: Subject: Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave To: sean.j.christopherson@intel.com Cc: jethro@fortanix.com, luto@kernel.org, Neil Horman , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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 > > > >