Linux-Sgx Archive on lore.kernel.org
 help / color / Atom feed
From: Jethro Beekman <jethro@fortanix.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
	"serge.ayoun@intel.com" <serge.ayoun@intel.com>,
	"shay.katz-zamir@intel.com" <shay.katz-zamir@intel.com>
Subject: Re: x86/sgx: v23-rc2
Date: Thu, 13 Feb 2020 15:10:24 +0100
Message-ID: <eaf66973-9c9b-b06c-4b96-134e41c18d80@fortanix.com> (raw)
In-Reply-To: <20191017175735.GD20903@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 3765 bytes --]

On 2019-10-17 19:57, Sean Christopherson wrote:
> +Cc Andy
> 
> On Mon, Oct 14, 2019 at 08:43:09AM +0000, Jethro Beekman wrote:
>> On 2019-10-11 20:15, Sean Christopherson wrote:
>>> On Fri, Oct 11, 2019 at 04:37:25PM +0000, Jethro Beekman wrote:
>>>> UAPI:
>>>>
>>>> This got a whole lot more complex for userspace compared to the out-of-tree
>>>> driver.
>>>>
>>>> 1. Manually needing to mmap a naturally-aligned memory region by allocating
>>>> too much memory and then unmapping parts is quite annoying. Why was the
>>>> auto-aligning removed? I think this will need to be handled the same for
>>>> every consumer of SGX, so I don't see why this is not handled in the kernel.
>>>> It never seems wrong to align if NULL is passed as the requested address.
>>>> Alternatively, is there room in the flags for a MAP_ALIGNED bit?
>>>
>>> I'm pretty sure everyone agrees it's annoying.  The short of it is that
>>> the SGX driver is the wrong place to do the alignment.  The driver could
>>> key off addr=0, but we don't want to take on that implicit behavior.
>>
>> Why not?
> 
> Because it's a hack.  If a MAP_ALIGNED flag is added then SGX is stuck
> with kludgy code that serves no purpose.  And userspace needs to manually
> align the result if it provides an actual hint.  Regardless of whether
> there are use cases for providing a hint for ELRANGE, having divergent
> logic is ugly.
> 
>>> A MAP_ALIGNED flag to have the allocation be naturally aligned is the
>>> ideal solution.  It's definitely something we should pursue, but that can
>>> and probably should be done in parallel to the SGX series.
>>>
>>>> 2. Having to re-open the device for every enclave is also annoying. This
>>>> means you need a filesystem available throughout the process lifetime. I
>>>> tried dup, but that doesn't work. Can we make dup work?
>>>
>>> The semantics of dup() won't get you what want, as dup() just creates a
>>> new descriptor pointing at the same file.
>>>
>>> An alternative solution that was proposed was to have an ioctl() for
>>> creating an enclave.  But that means using an anonymous inode, which runs
>>> afoul of SELinux permissions, e.g. every _process_ that runs enclaves
>>> would require EXECMEM.  Linus was quite clear that SGX wouldn't be merged
>>> if using it required users to degrade existing security.
>>
>> It's ok if it's the same inode, it just needs to be a different struct file.
>>
>>> I'm open to other ideas.  I wasn't aware this was a pain point and file
>>> stuff isn't exactly my area of expertise, so I haven't put much/any
>>> thought into alternatives.
>>
>> The default permissions for /dev/sgx/enclave are root-only. This means you
>> want to be able to do the same thing as network servers: initialize some
>> resources as root, then drop privileges. This used to mean opening /dev/sgx
>> and keeping the fd around which meant you could launch enclaves at will. With
>> the new API, this is no longer possible, you can only launch one enclave per
>> fd. Is there a different type of operation that doesn't just duplicate the fd
>> but also the struct file? If not, can we add an ioctl for that?
> 
> My approach to this would be to chown /dev/sgx/enclave so that it's owned
> by root but accessible to users belonging to an sgx-specific group, e.g.
> via a udev rule.
> 
>> There are other scenarios where it's not just the permissions on
>> /dev/sgx/enclave that are the problem but using the filesystem in general
>> that is. Maybe you've used seccomp to disable file operations, etc.
> 
> Andy and Jarkko, thoughts?

Folks, any more thoughts on how to resolve the issue that you need to call open() for every enclave?

--
Jethro Beekman | Fortanix


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4054 bytes --]

  reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 11:37 Jarkko Sakkinen
2019-10-10 13:37 ` Jarkko Sakkinen
2019-10-10 17:09   ` Sean Christopherson
2019-10-10 17:39     ` Sean Christopherson
2019-10-11 16:37 ` Jethro Beekman
2019-10-11 18:15   ` Sean Christopherson
2019-10-14  8:43     ` Jethro Beekman
2019-10-17 17:57       ` Sean Christopherson
2020-02-13 14:10         ` Jethro Beekman [this message]
2020-02-15  7:24           ` Jarkko Sakkinen
2020-02-17  8:52             ` Jethro Beekman
2020-02-17 18:55               ` Jarkko Sakkinen
2020-02-17 18:56                 ` Jarkko Sakkinen
2020-02-18 10:42                 ` Dr. Greg Wettstein
2020-02-18 15:00                   ` Andy Lutomirski
2020-02-18 15:52                   ` Jarkko Sakkinen

Reply instructions:

You may reply publically 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=eaf66973-9c9b-b06c-4b96-134e41c18d80@fortanix.com \
    --to=jethro@fortanix.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=serge.ayoun@intel.com \
    --cc=shay.katz-zamir@intel.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

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