Re: x86/sgx: v23-rc2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 18, 2020 at 05:52:47PM +0200, Jarkko Sakkinen wrote:

Good morning, I hope the day is going well for everyone.

> On Tue, Feb 18, 2020 at 04:42:43AM -0600, Dr. Greg Wettstein wrote:
> > I believe an accurate summary of Dr. Beekman's concerns are as
> > follows:
> > 
> > 1.) He envisions a need for an enclave orchestrator that uses root
> > privileges to open the SGX driver device and then drop privileges,
> > presumably in a permanent fashion.  The orchestrator would then use
> > the filehandle to load and initialize multiple enclaves on request.
> > 
> > 2.) The enclave orchestrator may be run in an environment that has
> > SECCOMP limitations on the ability to conduct filesystem operations.

> Also UDS sockets with SCM_RIGHTS should work.

The first clarification, I'm assuming you mean passing SCM_RIGHTS over
AF_UNIX/UNIX-domain sockets, not UDP sockets?

Secondly, it was my understanding that the reason major renovations to
the driver were initiated, almost a year ago now, was to create a
situation where there was a filehandle per enclave in order for the
LSM to get a 'look' at the executable TEXT that was being deployed to
the enclave.

It appears that the sgx_open() function, that is installed as the
->open method for the /dev/sgx/enclave device node, allocates the
master enclave definition structure, that is installed, and
subsequently released, as private data for the file instance object.
This master enclave structure has the reference to the virtual memory
definition for the enclave that is opened.

This would seem to imply that the driver is rather firmly architected
on the notion of one open() per enclave, a concept that Jethro seems
to have issues with.

> /Jarkko

Have a good day.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker
IDfusion, LLC               SGX secured infrastructure and
4206 N. 19th Ave.           autonomously self-defensive platforms.
Fargo, ND  58102
PH: 701-281-1686            EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"Artifical Intelligence stands no chance against Natural Stupidity."
                                -- John Henders



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux