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: Mon, 12 Jun 2017 16:00:17 -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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Andy Lutomirski , Jarkko Sakkinen , Kai Huang , Paolo Bonzini , Radim Krcmar , kvm list , "intel-sgx-kernel-dev@lists.01.org" , haim.cohen@intel.com To: "Huang, Kai" Return-path: Received: from mail.kernel.org ([198.145.29.99]:39596 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752789AbdFLXAk (ORCPT ); Mon, 12 Jun 2017 19:00:40 -0400 Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) (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 35B7523A0A for ; Mon, 12 Jun 2017 23:00:39 +0000 (UTC) Received: by mail-ua0-f178.google.com with SMTP id 68so47969270uas.0 for ; Mon, 12 Jun 2017 16:00:39 -0700 (PDT) In-Reply-To: <92f3b0cc-1f04-d8a5-9e86-0417f75f8ed9@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jun 12, 2017 at 3:08 PM, Huang, Kai wrote: > > I don't know whether SGX driver will have restrict on running provisioning > enclave. In my understanding provisioning enclave is always from Intel. > However I am not expert here and probably be wrong. Can you point out > *exactly* what restricts in host must/should be applied to guest so that > Jarkko can know whether he will support those restricts or not? Otherwise I > don't think we even need to talk about this topic at current stage. > The whole point is that I don't know. But here are two types of restriction I can imagine demand for: 1. Only a particular approved provisioning enclave may run (be it Intel's or otherwise -- with a non-Intel LE, I think you can launch a non-Intel provisioning enclave). This would be done to restrict what types of remote attestation can be done. (Intel supplies a remote attestation service that uses some contractual policy that I don't know. Maybe a system owner wants a different policy applied to ISVs.) Imposing this policy on guests more or less requires filtering EINIT. 2. For kiosk-ish or single-purpose applications, I can imagine that you would want to allow a specific list of enclave signers or even enclave hashes. Maybe you would allow exactly one enclave hash. You could kludge this up with a restrictive LE policy, but you could also do it for real by implementing the specific restriction in the kernel. Then you'd want to impose it on the guest, and you'd do it by filtering EINIT. For the time being, I don't expect either policy to be implemented right away, but I bet that something like this will eventually happen.