On Fri, 2023-05-26 at 19:32 -0500, Haitao Huang wrote: > Hi Kai, Jarkko and Dave > > On Thu, 09 Mar 2023 05:31:29 -0600, Huang, Kai <kai.huang@xxxxxxxxx> wrote: > > > > So I am still a little bit confused about where does "SGX driver uses > > MAP_ANONYMOUS semantics for fd-based mmap()" come from. > > > > Anyway, we certainly don't want to break userspace. However, IIUC, even > > from > > now on we change the driver to depend on userspace to pass the correct > > pgoff in > > mmap(), this won't break userspace, because old userspace which doesn't > > use > > fadvice() and pgoff actually doesn't matter. For new userspace which > > uses > > fadvice(), it needs to pass the correct pgoff. > > > > I am not saying we should do this, but it doesn't seem we can break > > userspace? > > > > Sorry for delayed update but I thought about this more and likely to > propose a new EAUG ioctl for this and for enabling SGX-CET shadow stack > pages. But regardless, I'd like to wrap up this discussion to just clarify > this anonymous semantics design in documentation so people won't get > confused in future. > > I think we all agree to keep this semantics so no user space would need > specify 'offset' for mmap with enclave fd. And here is my proposed > documentation changes. > > --- a/Documentation/x86/sgx.rst > +++ b/Documentation/x86/sgx.rst > @@ -100,6 +100,23 @@ pages and establish enclave page permissions. > sgx_ioc_enclave_init > sgx_ioc_enclave_provision > > +Enclave memory mapping > +---------------------- > + > +A file descriptor created from opening **/dev/sgx_enclave** represents an > +enclave object. The mmap() syscall with enclave file descriptors does not > +support non-zero value for the 'offset' parameter. I think we all need to understand better why SGX driver requires anonymous semantics mmap() against /dev/sgx_enclave, and as a result of that, requires mmap() to pass 0 as pgoff (which looks wasn't even discussed when upstreaming the driver). I'll do some investigation and try to summerize and report back. Thanks. [...] > This is > +unlike regular file mapping in that no content offset can be defined that > is > +independent from the virtual address it is loaded to. > + > Don't quite understand this. The virtual address of a regular file mapping can be linked to file's offest from VMA's pgoff.
