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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 C51F9C4360C for ; Wed, 25 Sep 2019 16:49:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9DA22207E0 for ; Wed, 25 Sep 2019 16:49:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2502163AbfIYQte (ORCPT ); Wed, 25 Sep 2019 12:49:34 -0400 Received: from mga18.intel.com ([134.134.136.126]:55094 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731087AbfIYQtd (ORCPT ); Wed, 25 Sep 2019 12:49:33 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2019 09:49:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,548,1559545200"; d="scan'208";a="193831908" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.41]) by orsmga006.jf.intel.com with ESMTP; 25 Sep 2019 09:49:32 -0700 Date: Wed, 25 Sep 2019 09:49:32 -0700 From: Sean Christopherson To: Borislav Petkov Cc: Jarkko Sakkinen , linux-kernel@vger.kernel.org, x86@kernel.org, linux-sgx@vger.kernel.org, akpm@linux-foundation.org, dave.hansen@intel.com, nhorman@redhat.com, npmccallum@redhat.com, serge.ayoun@intel.com, shay.katz-zamir@intel.com, haitao.huang@intel.com, andriy.shevchenko@linux.intel.com, tglx@linutronix.de, kai.svahn@intel.com, josh@joshtriplett.org, luto@kernel.org, kai.huang@intel.com, rientjes@google.com, cedric.xing@intel.com, Kai Huang , Haim Cohen Subject: Re: [PATCH v22 02/24] x86/cpufeatures: x86/msr: Intel SGX Launch Control hardware bits Message-ID: <20190925164932.GE31852@linux.intel.com> References: <20190903142655.21943-1-jarkko.sakkinen@linux.intel.com> <20190903142655.21943-3-jarkko.sakkinen@linux.intel.com> <20190924155232.GG19317@zn.tnic> <20190925140903.GA19638@linux.intel.com> <20190925151949.GE3891@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190925151949.GE3891@zn.tnic> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 25, 2019 at 05:19:49PM +0200, Borislav Petkov wrote: > On Wed, Sep 25, 2019 at 05:09:03PM +0300, Jarkko Sakkinen wrote: > > The driver will support only the case where the bit is set i.e. that > > it can freely write to the MSRs MSR_IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}. > > It will refuse to initialize otherwise. > > See this: > > https://lkml.kernel.org/r/20190925085156.GA3891@zn.tnic > > AFAICT, when FEATURE_CONTROL_SGX_LE_WR is not set, you're not clearing > all SGX feature bits. But you should, methinks. Correct, only X86_FEATURE_SGX_LC is cleared. The idea is to have SGX_LC reflect whether or not flexible launch control is fully enabled, no more no less. Functionally, this doesn't impact support for native enclaves as the driver will refuse to load if SGX_LC=0. Looking forward, this *will* affect KVM. As proposed, KVM would expose SGX to a guest regardless of SGX_LC support. https://lkml.kernel.org/r/20190727055214.9282-17-sean.j.christopherson@intel.com