All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christopherson, Sean J" <sean.j.christopherson@intel.com>
To: 'Andy Lutomirski' <luto@kernel.org>,
	"Huang, Kai" <kai.huang@linux.intel.com>
Cc: "intel-sgx-kernel-dev@lists.01.org"
	<intel-sgx-kernel-dev@lists.01.org>,
	kvm list <kvm@vger.kernel.org>, Radim Krcmar <rkrcmar@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: RE: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support
Date: Fri, 16 Jun 2017 16:31:28 +0000	[thread overview]
Message-ID: <37306EFA9975BE469F115FDE982C075BC61162A2@ORSMSX108.amr.corp.intel.com> (raw)
In-Reply-To: <CALCETrVAmQaoVFYAmi9LepVe+-SRSvSiqcr8pfrLVp-H1KVOiQ@mail.gmail.com>

Andy Lutomirski <luto@kernel.org> wrote:
> On Thu, Jun 15, 2017 at 9:33 PM, Huang, Kai <kai.huang@linux.intel.com> wrote:
> >
> >
> > On 6/16/2017 4:11 PM, Andy Lutomirski wrote:
> >>
> >> On Thu, Jun 15, 2017 at 8:46 PM, Huang, Kai <kai.huang@linux.intel.com>
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 6/13/2017 11:00 AM, Andy Lutomirski wrote:
> >>>>
> >>>>
> >>>> On Mon, Jun 12, 2017 at 3:08 PM, Huang, Kai <kai.huang@linux.intel.com>
> >>>> 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.
> >>>
> >>>
> >>>
> >>> Hi Andy,
> >>>
> >>> Sorry for late reply.
> >>>
> >>> What is the issue if host and guest run provisioning enclave from
> >>> different
> >>> vendor, for example, host runs intel's provisioning enclave, and guest
> >>> runs
> >>> other vendor's provisioning enclave? Or different guests run provisioning
> >>> enclaves from different vendors?
> >>
> >>
> >> There's no issue unless someone has tried to impose a policy.  There
> >> is clearly at least some interest in having policies that affect what
> >> enclaves can run -- otherwise there wouldn't be LEs in the first
> >> place.
> >>
> >>>
> >>> One reason I am asking is that, on Xen (where we don't have concept of
> >>> *host*), it's likely that we won't apply any policy at Xen hypervisor at
> >>> all, and guests will be able to run any enclave from any signer as their
> >>> wish.
> >>
> >>
> >> That seems entirely reasonable.  Someone may eventually ask Xen to add
> >> support for SGX enclave restrictions, in which case you'll either have
> >> to tell them that it won't happen or implement it.
> >>
> >>>
> >>> Sorry that I don't understand (or kind of forgot) the issues here.
> >>>
> >>>>
> >>>> 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.
> >>>
> >>>
> >>> Assuming the enclave hash means measurement of enclave, and assuming we
> >>> have
> >>> a policy that we only allow enclave from one signer to run, would you
> >>> also
> >>> elaborate the issue that, if host and guest run enclaves from different
> >>> signer? If host has such policy, and we are allowing creating guests on
> >>> such
> >>> host, I think that typically we will have the same policy in the guest
> >>
> >>
> >> Yes, I presume this too, but.
> >>
> >>> (vetted by guest's kernel). The owner of that host should be aware of the
> >>> risk (if there's any) by creating guest and run enclave inside it.
> >>
> >>
> >> No.  The host does not trust the guest in general.  If the host has a
> >
> >
> > I agree.
> >
> >> policy that the only enclave that shall run is X, that doesn't mean
> >> that the host shall reject all enclaves requested by the normal
> >> userspace API except X but that, if /dev/kvm is used, then the user is
> >> magically trusted to not load a guest that fails to respect the host
> >> policy.  It means that the only enclave that shall run is X regardless
> >> of what interface is used.  The host must only allow X to be loaded by
> >> its userspace and the host must only allow X to be loaded by a guest.
> >>
> >
> > This is theoretical thing. I think your statement makes sense only if we
> > have specific example that can prove there's actual risk when allowing guest
> > to exceed X approved by host.
> >
> > I will dig more in your previous emails to see whether you have listed such
> > real cases (I some kind forgot sorry) but if you don't mind, you can list
> > such cases here.
> 
> I'm operating under the assumption that some kind of policy exists in
> the first place.  I can imagine everything working fairly well without
> any real policy, but apparently there are vendors who want restrictive
> policies.  What I can't imagine is anyone who wants a restrictive
> policy but is then okay with the host only partially enforcing it.

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.

[1] On a system with unlocked IA32_SGXLEPUBKEYHASH MSRs, the only value added
by a using a LE to enforce the kernel's policies is defense-in-depth, e.g. an
attacker can't hide malicious code in an enclave even if it gains control of
the kernel.  I think this is a very minor benefit since running in an enclave
doesn't grant any new privileges and doesn't persist across system reset.

[2] I think it's safe to assume that any use case that requires locked hash
MSRs is out of scope for this discussion, given that the upstream kernel will
require unlocked MSRs.

  reply	other threads:[~2017-06-16 16:31 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-08  5:24 [RFC PATCH 00/10] Basic KVM SGX Virtualization support Kai Huang
2017-05-08  5:24 ` [PATCH 01/10] x86: add SGX Launch Control definition to cpufeature Kai Huang
2017-05-08  5:24 ` [PATCH 02/10] kvm: vmx: add ENCLS VMEXIT detection Kai Huang
2017-05-08  5:24 ` [PATCH 03/10] kvm: vmx: detect presence of host SGX driver Kai Huang
2017-05-08  5:24 ` [PATCH 04/10] kvm: sgx: new functions to init and destory SGX for guest Kai Huang
2017-05-08  5:24 ` [PATCH 05/10] kvm: x86: add KVM_GET_SUPPORTED_CPUID SGX support Kai Huang
2017-05-08  5:24 ` [PATCH 06/10] kvm: x86: add KVM_SET_CPUID2 " Kai Huang
2017-05-08  5:24 ` [PATCH 07/10] kvm: vmx: add SGX IA32_FEATURE_CONTROL MSR emulation Kai Huang
2017-05-08  5:24 ` [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support Kai Huang
2017-05-12  0:32   ` Huang, Kai
2017-05-12  3:28     ` [intel-sgx-kernel-dev] " Andy Lutomirski
2017-05-12  4:56       ` Huang, Kai
2017-05-12  6:11         ` Andy Lutomirski
2017-05-12 18:48           ` Christopherson, Sean J
2017-05-12 20:50             ` Christopherson, Sean J
2017-05-16  0:59             ` Huang, Kai
2017-05-16  1:22             ` Huang, Kai
2017-05-16  0:48           ` Huang, Kai
2017-05-16 14:21             ` Paolo Bonzini
2017-05-18  7:54               ` Huang, Kai
2017-05-18  8:58                 ` Paolo Bonzini
2017-05-17  0:09             ` Andy Lutomirski
2017-05-18  7:45               ` Huang, Kai
2017-06-06 20:52                 ` Huang, Kai
2017-06-06 21:22                   ` Andy Lutomirski
2017-06-06 22:51                     ` Huang, Kai
2017-06-07 14:45                       ` Cohen, Haim
2017-06-08 12:31                   ` Jarkko Sakkinen
2017-06-08 23:47                     ` Huang, Kai
2017-06-08 23:53                       ` Andy Lutomirski
2017-06-09 15:38                         ` Cohen, Haim
2017-06-10 12:23                       ` Jarkko Sakkinen
2017-06-11 22:45                         ` Huang, Kai
2017-06-12  8:36                           ` Jarkko Sakkinen
2017-06-12  9:53                             ` Huang, Kai
2017-06-12 16:24                               ` Andy Lutomirski
2017-06-12 22:08                                 ` Huang, Kai
2017-06-12 23:00                                   ` Andy Lutomirski
2017-06-16  3:46                                     ` Huang, Kai
2017-06-16  4:11                                       ` Andy Lutomirski
2017-06-16  4:33                                         ` Huang, Kai
2017-06-16  9:34                                           ` Huang, Kai
2017-06-16 16:03                                           ` Andy Lutomirski
2017-06-16 16:25                                           ` Andy Lutomirski
2017-06-16 16:31                                             ` Christopherson, Sean J [this message]
2017-06-16 16:43                                               ` Andy Lutomirski
2017-06-13 18:57                               ` Jarkko Sakkinen
2017-06-13 19:05                                 ` Jarkko Sakkinen
2017-06-13 20:13                                   ` Sean Christopherson
2017-06-14  9:37                                     ` Jarkko Sakkinen
2017-06-14 15:11                                       ` Christopherson, Sean J
2017-06-14 17:03                                         ` Jarkko Sakkinen
2017-06-13 23:28                                 ` Huang, Kai
2017-06-14  9:44                                   ` Jarkko Sakkinen
2017-07-19 15:04           ` Sean Christopherson
2017-05-15 12:46       ` Jarkko Sakkinen
2017-05-15 23:56         ` Huang, Kai
2017-05-16 14:23           ` Paolo Bonzini
2017-05-17 14:21           ` Sean Christopherson
2017-05-18  8:14             ` Huang, Kai
2017-05-20 21:55               ` Andy Lutomirski
2017-05-23  5:43                 ` Huang, Kai
2017-05-23  5:55                   ` Huang, Kai
2017-05-23 16:34                   ` Andy Lutomirski
2017-05-23 16:43                     ` Paolo Bonzini
2017-05-24  8:20                       ` Huang, Kai
2017-05-20 13:23           ` Jarkko Sakkinen
2017-05-08  5:24 ` [PATCH 09/10] kvm: vmx: handle ENCLS VMEXIT Kai Huang
2017-05-08  8:08   ` Paolo Bonzini
2017-05-10  1:30     ` Huang, Kai
2017-05-08  5:24 ` [PATCH 10/10] kvm: vmx: handle VMEXIT from SGX Enclave Kai Huang
2017-05-08  8:22   ` Paolo Bonzini
2017-05-11  9:34     ` Huang, Kai
2017-06-19  5:02       ` Huang, Kai
2017-06-27 15:29         ` Radim Krčmář
2017-06-28 22:22           ` Huang, Kai
2017-05-08  5:24 ` [PATCH 11/11] kvm: vmx: workaround FEATURE_CONTROL[17] is not set by BIOS Kai Huang
2017-05-08  5:29   ` Huang, Kai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37306EFA9975BE469F115FDE982C075BC61162A2@ORSMSX108.amr.corp.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=intel-sgx-kernel-dev@lists.01.org \
    --cc=kai.huang@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.