Linux-Sgx Archive on lore.kernel.org
 help / color / Atom feed
From: Nathaniel McCallum <npmccallum@redhat.com>
To: "Dr. Greg" <greg@enjellic.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
	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,
	Neil Horman <nhorman@redhat.com>,
	"Huang, Haitao" <haitao.huang@intel.com>,
	andriy.shevchenko@linux.intel.com, "Svahn,
	Kai" <kai.svahn@intel.com>,
	bp@alien8.de, Josh Triplett <josh@joshtriplett.org>,
	luto@kernel.org, kai.huang@intel.com,
	David Rientjes <rientjes@google.com>,
	"Xing, Cedric" <cedric.xing@intel.com>,
	Patrick Uiterwijk <puiterwijk@redhat.com>
Subject: Re: [PATCH v29 00/20] Intel SGX foundations
Date: Fri, 15 May 2020 15:54:40 -0400
Message-ID: <CAOASepNdOqsoYvPPf7+0_qU70JBMb9GMONrGX+jdt=SQtT1X8g@mail.gmail.com> (raw)
In-Reply-To: <20200514091637.GA25156@wind.enjellic.com>

On Thu, May 14, 2020 at 5:17 AM Dr. Greg <greg@enjellic.com> wrote:
>
> 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.

The (Red Hat sponsored) Enarx project will continue building an
unofficial, unsupported version of the Fedora kernel with the SGX
patches[0] until such time as the patches are upstream. Once upstream,
I intend to propose that the feature be enabled in the stock Fedora
kernel.

Enarx requires EDMM support as a prerequisite to being production
ready. Therefore, we are likely to continue building this custom
Fedora kernel with the latest patches until such point as EDMM support
lands upstream. This also implies that I have no current plan to
request an SGX backport to a RHEL kernel until such time as it
supports our full needs.

Disclaimer: I do not control RHEL or Fedora kernel features. None of
the above constitutes a commitment to deliver anything.

[0]: https://copr.fedorainfracloud.org/coprs/npmccallum/enarx/package/kernel/

> 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
>


  parent 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
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 [this message]
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='CAOASepNdOqsoYvPPf7+0_qU70JBMb9GMONrGX+jdt=SQtT1X8g@mail.gmail.com' \
    --to=npmccallum@redhat.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=greg@enjellic.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=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