From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support Date: Fri, 16 Jun 2017 09:43:31 -0700 Message-ID: References: <6ab7ec4e-e0fa-af47-11b2-f26edcb088fb@linux.intel.com> <596dc1ad-eac7-798d-72e5-665eb7f3f2e4@linux.intel.com> <0b4697b9-0976-c8ad-e26f-4ff683318486@linux.intel.com> <20170608123101.47pgsaovkgtdxaw4@intel.com> <46bdaa22-8e7d-738f-9dd0-840fe3327506@linux.intel.com> <20170610122306.lfjshzepqxxyqj72@intel.com> <001ecd91-15e7-ef5a-097b-d57bc7784f47@linux.intel.com> <20170612083658.vrrcr6dq6axiovse@intel.com> <3bbe95fe-bb97-d430-e9d3-d4edcb381f46@linux.intel.com> <92f3b0cc-1f04-d8a5-9e86-0417f75f8ed9@linux.intel.com> <91b9e29f-fc15-7524-3740-4417d3a1dd8f@linux.intel.com> <37306EFA9975BE469F115FDE982C075BC61162A2@ORSMSX108.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Andy Lutomirski , "Huang, Kai" , "intel-sgx-kernel-dev@lists.01.org" , kvm list , Radim Krcmar , Paolo Bonzini To: "Christopherson, Sean J" Return-path: Received: from mail.kernel.org ([198.145.29.99]:49460 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbdFPQnx (ORCPT ); Fri, 16 Jun 2017 12:43:53 -0400 Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E51B5239C3 for ; Fri, 16 Jun 2017 16:43:52 +0000 (UTC) Received: by mail-ua0-f175.google.com with SMTP id j53so15132462uaa.2 for ; Fri, 16 Jun 2017 09:43:52 -0700 (PDT) In-Reply-To: <37306EFA9975BE469F115FDE982C075BC61162A2@ORSMSX108.amr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Jun 16, 2017 at 9:31 AM, Christopherson, Sean J wrote: > I think there is a certain amount of inception going on here, i.e. the only > reason we're discussing LE enforced policies in the kernel is because the LE > architecture exists and can't be disabled. The LE, as originally designed, > is intended to be a way for *userspace* to control what code can run on the > system, e.g. to provide a hook for anti-virus/malware to inspect an enclave > since it's impossible to inspect an enclave once it is running. > > The kernel doesn't need an LE to restrict what enclaves can run, e.g. it can > perform inspection at any point during the initialization process. This is > true for guest enclaves as well since the kernel can trap EINIT. By making > the LE kernel-only we've bastardized the concept of the LE and have negated > the primary value provided by an LE[1][2]. In my opinion, the discussion of > the kernel's launch policies is much ado about nothing, e.g. if supported by > hardware, I think we'd opt to disable launch control completely. Agreed. I don't think I've ever said that the kernel should implement restrictions on what enclaves should run [1]. All I've said is that (a) if the kernel does implement restrictions like this, it should apply them to guests as well and (b) that the kernel should probably trap EINIT because that's the most sensible way to deal with the MSRs. [1] With the possible exception of provisioning enclaves. I'm still not convinced that anyone except root should be allowed to run an exclave with the provision bit set, as that bit gives access to the provisioning key, which is rather special. From memory, it bypasses the owner epoch, and it may have privacy issues. Maybe this is a nonissue, but I'd like to see someone seriously analyze how provisioning enclaves that may not be signed by Intel affect the overall security of the system and how Linux should handle them. SGX was designed under the assumption that provisioning enclaves would only ever be signed by Intel, and that's not the case any more, and dealing with this intelligently may require some thought.