Linux-Sgx Archive on lore.kernel.org
 help / color / Atom feed
From: "Dr. Greg" <greg@enjellic.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	torvalds@linux-foundation.org, 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,
	haitao.huang@intel.com, andriy.shevchenko@linux.intel.com,
	kai.svahn@intel.com, bp@alien8.de, josh@joshtriplett.org,
	luto@kernel.org, kai.huang@intel.com, rientjes@google.com,
	cedric.xing@intel.com, puiterwijk@redhat.com
Subject: Re: [PATCH v29 00/20] Intel SGX foundations
Date: Thu, 14 May 2020 04:16:37 -0500
Message-ID: <20200514091637.GA25156@wind.enjellic.com> (raw)
In-Reply-To: <20200508195635.GR27052@linux.intel.com>

On Fri, May 08, 2020 at 12:56:35PM -0700, Sean Christopherson wrote:

Good morning, I hope the week is proceeding well for everyone.

> On Fri, May 08, 2020 at 02:02:26PM -0500, Dr. Greg wrote:
> > On Thu, May 07, 2020 at 02:41:30AM +0200, Thomas Gleixner wrote:
> > > The diffstat of your patch is irrelevant. What's relevant is the
> > > fact that it is completely unreviewed and that it creates yet
> > > another user space visible ABI with a noticable lack of
> > > documentation.
> 
> ...
> 
> > As to lack of review, we would certainly welcome technical and API
> > comments but we cannot force them.

> Thomas' point isn't that your code needs to be reviewed, it's that
> trying to squeeze it into the initial merge will, not might, _will_
> push out the acceptance of SGX.  The same is true for other features
> we have lined up, e.g. KVM and cgroup support.  It's not a slight on
> your code, it's just reality at this point.

For the record and for whatever it is worth at this point.  The patch
has been available in its present form and function for around 14
months.

So there was plenty of time for its consideration and integration into
what is being prepared as the final merge candidate.

> > In fact, anyone who reviews the patch will see that the current driver
> > creates a pointer in the ioctl call to pass downward into the hardware
> > initialization routines.  Our code simply replaces that pointer with
> > one supplied by userspace.

> Personally, I'm in favor of adding a reserved placeholder for a
> token so as to avoid adding a second ioctl() in the event that
> something gets upstreamed that wants the token.  Ditto for a file
> descriptor for the backing store in sgx_enclave_create.

That would be a very low cost and forward looking addition.

> > At the very least a modular form of the driver should be
> > considered that would allow alternate implementations.  Sean
> > indicated that there was a 'kludgy' approach that would allow an
> > alternate modular implementation alongside the in-kernel driver.
> > I believe that Andy has already indicated that may not be an
> > advisable approach.

> Modularizing the the driver does nothing for your use case.  The
> "driver" is a relatively lightweight wrapper, removing that is akin
> to making /dev/sgx/enclave inaccessible, i.e. it doesn't make the
> EPC tracking and core code go away.  Modularizing the whole thing is
> flat out not an option, as doing so is not compatible with an EPC
> cgroup and adds unnecessary complexity to KVM enabling, both of
> which are highly desired features by pretty much everyone that plans
> on using SGX.

All well taken technical points, but they don't speak directly to the
issue at hand.  The potential security issue in all of this is access
to /dev/sgx/enclave, not the EPC tracking and core code.

Here in a nutshell is the paradox the kernel faces:

No one seems to be disputing the fact that the primary focus of this
driver will be to support the notion of 'runtime encryption' and
Confidential Computing.  The whole premise of the concept and economic
predicate of the initiative is that the owner/manager of the platform
has no visibility into what is being done on the platform.

If the Linux community believes that standard platform security
controls can make qualitatively good judgements on what enclave based
execution is doing, it is effectively making the statement that the
very concept of runtime encryption and by extension Confidential
Computing is invalid.

If we accept the concept that Confidential Computing is valid then we
admit the technology provides the opportunity for unsupervised code
execution and data manipulation.

Our premise in all of this is that one page of code implementing three
linked lists is a small price to pay to provide platform owners with
the opportunity to optionally implement what is effectively 2-factor
authentication over this process.

Going forward, if we are intellectually honest, all of this suggests
that adding complexity to the driver with LSM controls makes little
sense technically.  Since, by definition and economic intent, the
technology provides tools and infrastructure that allows these
controls to be evaded.

The notion that entities with adversarial intent would not try and
take advantage of this flies in the face of everything we know about
security.

> Andy is right to caution against playing games to squish in-kernel
> things, but the virtualization snafu is a completely different
> beast.  E.g. SGX doesn't require fiddling with CR4, won't corrupt
> random memory across kexec(), doesn't block INIT, etc...  And I'm
> not advocating long-term shenanigans, I just wanted to point out
> that there are options for running out-of-tree drivers in the short
> term, e.g. until proper policy controls land upstream.

It appears that the distributions, at least IBM/RHEL, are going to
compile this driver in and backport it as well.

What we would recommend at this point is that you and Jarkko do the
Linux community and beyond a favor and wire up a simple kernel
command-line parameter that controls the ability of the driver to be
used, ie. enables/disables access to /dev/sgx/enclave.

Distributions or others can set this command-line parameter by default
to 'disable' and avoid any possibility of the technology being used
for nefarious purposes.  Since the technology now appears to be
focused only on the cloud providers they will certainly be capable of
configuring their implementations to change the default.

In essence, make the kernel's behavior secure by default.

Best wishes for a pleasant weekend to everyone.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Artisans in autonomously
Enjellic Systems Development, LLC     self-defensive IOT platforms
4206 N. 19th Ave.                     and edge devices.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Intellectuals solve problems; geniuses prevent them."
                                -- Albert Einstein

  reply index

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21 21:52 Jarkko Sakkinen
2020-04-21 21:52 ` [PATCH v29 01/20] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
2020-04-21 21:52 ` [PATCH v29 02/20] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
2020-04-21 21:52 ` [PATCH v29 03/20] x86/cpufeatures: x86/msr: Intel SGX Launch Control " Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 04/20] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 05/20] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 06/20] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 07/20] x86/cpu/intel: Detect SGX support Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 08/20] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 09/20] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 10/20] mm: Introduce vm_ops->may_mprotect() Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 11/20] x86/sgx: Linux Enclave Driver Jarkko Sakkinen
2020-05-08 19:09   ` Sean Christopherson
2020-04-21 21:53 ` [PATCH v29 12/20] x86/sgx: Add provisioning Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 13/20] x86/sgx: Add a page reclaimer Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 14/20] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
2020-05-06 21:50   ` Sean Christopherson
2020-05-13 21:40     ` Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 15/20] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 16/20] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 17/20] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 18/20] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 19/20] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2020-04-21 21:53 ` [PATCH v29 20/20] docs: x86/sgx: Document SGX micro architecture and kernel internals Jarkko Sakkinen
2020-04-22 16:48 ` [PATCH v29 00/20] Intel SGX foundations Connor Kuehl
2020-04-29  5:22   ` Jarkko Sakkinen
2020-04-26 16:57 ` Dr. Greg
2020-04-29  5:23   ` Jarkko Sakkinen
2020-04-29 15:14     ` Sean Christopherson
2020-04-30  3:59       ` Jarkko Sakkinen
2020-05-02 23:05         ` Dr. Greg
2020-05-03  0:48           ` Andy Lutomirski
2020-05-04  9:34             ` Dr. Greg
2020-04-29 15:30   ` Sean Christopherson
2020-05-08  0:40     ` Andy Lutomirski
2020-05-07  0:41   ` Thomas Gleixner
2020-05-08 19:02     ` Dr. Greg
2020-05-08 19:56       ` Sean Christopherson
2020-05-14  9:16         ` Dr. Greg [this message]
2020-05-14 16:15           ` Sean Christopherson
2020-05-14 16:20             ` Borislav Petkov
2020-05-14 19:29               ` Thomas Gleixner
2020-05-15  9:28               ` Jarkko Sakkinen
2020-05-15  9:42                 ` Borislav Petkov
2020-05-15 16:24                   ` Jarkko Sakkinen
2020-05-15  0:09             ` Jarkko Sakkinen
2020-05-15 19:54           ` Nathaniel McCallum
2020-05-16  9:58             ` Jarkko Sakkinen
2020-05-24 21:27           ` Pavel Machek
2020-05-26  8:16             ` David Laight
2020-04-26 17:03 ` Dr. Greg
2020-04-29 15:27 ` Jethro Beekman
2020-04-30  3:46   ` Jarkko Sakkinen
2020-04-30  7:19     ` Jethro Beekman
2020-04-30  8:23       ` Jarkko Sakkinen
2020-04-30 14:12         ` Jethro Beekman
2020-05-06 12:16           ` Jarkko Sakkinen
2020-05-06 16:39 ` Jordan Hand
2020-05-07 18:06   ` Dr. Greg
2020-05-08 16:16     ` Jordan Hand
2020-05-13 23:09   ` Jarkko Sakkinen
2020-05-06 21:42 ` Nathaniel McCallum
2020-05-06 22:14   ` Sean Christopherson
2020-05-07  5:02     ` Haitao Huang
2020-05-07 16:49       ` Nathaniel McCallum
2020-05-07 19:34         ` Sean Christopherson
2020-05-07 22:35           ` Haitao Huang
2020-05-08  0:25             ` Sean Christopherson
2020-05-28 11:15               ` Jarkko Sakkinen
2020-05-28 11:19                 ` Jarkko Sakkinen
2020-05-07 22:31         ` Haitao Huang
2020-05-13 22:14   ` Jarkko Sakkinen
2020-05-13 22:18     ` Jarkko Sakkinen
2020-05-14  6:31     ` Jethro Beekman
2020-05-14 19:30     ` Thomas Gleixner
2020-05-15  0:22       ` Jarkko Sakkinen
2020-05-08 19:08 ` Sean Christopherson
2020-05-14 19:05   ` Seth Moore
2020-05-15  0:23     ` Jarkko Sakkinen
2020-05-12 11:55 ` Hui, Chunyang
2020-05-12 16:51   ` Dr. Greg
2020-05-14 10:49   ` Jarkko Sakkinen
2020-05-16  8:53 ` [PATCH] x86/cpu/intel: Add nosgx kernel parameter Jarkko Sakkinen

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=20200514091637.GA25156@wind.enjellic.com \
    --to=greg@enjellic.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=cedric.xing@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=haitao.huang@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=josh@joshtriplett.org \
    --cc=kai.huang@intel.com \
    --cc=kai.svahn@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=puiterwijk@redhat.com \
    --cc=rientjes@google.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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

Linux-Sgx Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-sgx/0 linux-sgx/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-sgx linux-sgx/ https://lore.kernel.org/linux-sgx \
		linux-sgx@vger.kernel.org
	public-inbox-index linux-sgx

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-sgx


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git