Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support

From: Andy Lutomirski <luto@kernel.org>
To: "Christopherson, Sean J" <sean.j.christopherson@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>,
	"Huang, Kai" <kai.huang@linux.intel.com>,
	"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 09:43:31 -0700	[thread overview]
Message-ID: <CALCETrVDz=rfZWDqtPfZytHfE8aFOPVWSu46bvoFWsgbf+7XAA@mail.gmail.com> (raw)
In-Reply-To: <37306EFA9975BE469F115FDE982C075BC61162A2@ORSMSX108.amr.corp.intel.com>

On Fri, Jun 16, 2017 at 9:31 AM, Christopherson, Sean J
<sean.j.christopherson@intel.com> 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.