On Mon, Mar 28, 2022 at 04:22:35PM -0700, Reinette Chatre wrote: > Hi Jarkko, > > On 3/19/2022 5:24 PM, Jarkko Sakkinen wrote: > > On Thu, Mar 17, 2022 at 05:11:40PM -0700, Reinette Chatre wrote: > >> Hi Jarkko, > >> > >> On 3/17/2022 3:51 PM, Jarkko Sakkinen wrote: > >>> On Thu, Mar 17, 2022 at 03:08:04PM -0700, Reinette Chatre wrote: > >>>> Hi Jarkko, > >>>> > >>>> On 3/16/2022 9:30 PM, Jarkko Sakkinen wrote: > >>>>> On Mon, Mar 14, 2022 at 08:32:28AM -0700, Reinette Chatre wrote: > >>>>>> Hi Jarkko, > >>>>>> > >>>>>> On 3/13/2022 8:42 PM, Jarkko Sakkinen wrote: > >>>>>>> On Fri, Mar 11, 2022 at 11:28:27AM -0800, Reinette Chatre wrote: > >>>>>>>> Supporting permission restriction in an ioctl() enables the runtime to manage > >>>>>>>> the enclave memory without needing to map it. > >>>>>>> > >>>>>>> Which is opposite what you do in EAUG. You can also augment pages without > >>>>>>> needing the map them. Sure you get that capability, but it is quite useless > >>>>>>> in practice. > >>>>>>> > >>>>>>>> I have considered the idea of supporting the permission restriction with > >>>>>>>> mprotect() but as you can see in this response I did not find it to be > >>>>>>>> practical. > >>>>>>> > >>>>>>> Where is it practical? What is your application? How is it practical to > >>>>>>> delegate the concurrency management of a split mprotect() to user space? > >>>>>>> How do we get rid off a useless up-call to the host? > >>>>>>> > >>>>>> > >>>>>> The email you responded to contained many obstacles against using mprotect() > >>>>>> but you chose to ignore them and snipped them all from your response. Could > >>>>>> you please address the issues instead of dismissing them? > >>>>> > >>>>> I did read the whole email but did not see anything that would make a case > >>>>> for fully exposed EMODPR, or having asymmetrical towards how EAUG works. > >>>> > >>>> I believe that on its own each obstacle I shared with you is significant enough > >>>> to not follow that approach. You simply respond that I am just not making a > >>>> case without acknowledging any obstacle or providing a reason why the obstacles > >>>> are not valid. > >>>> > >>>> To help me understand your view, could you please respond to each of the > >>>> obstacles I list below and how it is not an issue? > >>>> > >>>> > >>>> 1) ABI change: > >>>> mprotect() is currently supported to modify VMA permissions > >>>> irrespective of EPCM permissions. Supporting EPCM permission > >>>> changes with mprotect() would change this behavior. > >>>> For example, currently it is possible to have RW enclave > >>>> memory and support multiple tasks accessing the memory. Two > >>>> tasks can map the memory RW and later one can run mprotect() > >>>> to reduce the VMA permissions to read-only without impacting > >>>> the access of the other task. > >>>> By moving EPCM permission changes to mprotect() this usage > >>>> will no longer be supported and current behavior will change. > >>> > >>> Your concurrency scenario is somewhat artificial. Obviously you need to > >>> synchronize somehow, and breaking something that could be done with one > >>> system call into two separates is not going to help with that. On the > >>> contrary, it will add a yet one more difficulty layer. > >> > >> This is about supporting multiple threads in a single enclave, they can > >> all have their own memory mappings based on the needs. This is currently > >> supported in mainline as part of SGX1. > > > Could you please comment on the above? I've probably spent probably over two weeks of my life addressing concerns to the point that I feel as I was implementing this feature (that could be faster way to get it done). So I'll just wait the next version and see how it is like and give my feedback based on that. It's not really my problem to address every possible concern. BR, Jarkko
