On Wed, Jun 19, 2019 at 03:23:56PM -0700, Sean Christopherson wrote: > enclave_map() is an SGX specific variant of file_mprotect() and > mmap_file(), and is provided so that LSMs can apply W^X restrictions to > enclaves. > > Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave > VMAs are backed by a single file, i.e. /dev/sgx/enclave, that must be > MAP_SHARED. Furthermore, all enclaves need read, write and execute > VMAs. As a result, applying W^X restrictions on /dev/sgx/enclave using > existing LSM hooks is for all intents and purposes impossible, e.g. > denying either W or X would deny access to any enclave. > > Note, extensive discussion yielded no sane alternative to some form of > SGX specific LSM hook[1]. > > [1] https://lkml.kernel.org/r/CALCETrXf8mSK45h7sTK5Wf+pXLVn=Bjsc_RLpgO-h-qdzBRo5Q@xxxxxxxxxxxxxx > > Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> All the non-LSM changes are almost cleared from my part. I would suggest that we scrape v21 together as soon as you return from your vacation discluding the LSM hooks. There is no any particular reason to get the LSM changes to the mainline before the SGX foundations so now is the right time close things underlying them. I'm now in the same boat with your changes to the ioctl API, which means that we are ready to go. I feel a tiny bit bad that it took me so long time with [1] but I'm a simple minded person so what I can do :-) Once you can come back please deal with the suggestions that I made and provide a "pure" SRCU patch (apologies for repeating myself). I will the squash them to the existing patch set. After that is fully done we can make v21 scope decision when it comes to the enclave life-cycle. Even if the LSM changes would not be upstreamed as part of the foundations I can start holding versions of them in my tree but only after v21 is out. Can you cope with this plan? [1] https://patchwork.kernel.org/patch/11005431/ /Jarkko
