| Message ID | 20200915112842.897265-11-jarkko.sakkinen@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Intel SGX foundations | expand |
On Tue, Sep 15, 2020 at 02:28:28PM +0300, Jarkko Sakkinen wrote: > From: Sean Christopherson <sean.j.christopherson@intel.com> > > Add vm_ops()->mprotect() for additional constraints for a VMA. > > Intel Software Guard eXtensions (SGX) will use this callback to add two > constraints: > > 1. Verify that the address range does not have holes: each page address > must be filled with an enclave page. > 2. Verify that VMA permissions won't surpass the permissions of any enclave > page within the address range. Enclave cryptographically sealed > permissions for each page address that set the upper limit for possible > VMA permissions. Not respecting this can cause #GP's to be emitted. > > Cc: linux-mm@kvack.org > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Matthew Wilcox <willy@infradead.org> > Acked-by: Jethro Beekman <jethro@fortanix.com> > Reviewed-by: Darren Kenny <darren.kenny@oracle.com> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> > Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > --- > include/linux/mm.h | 3 +++ > mm/mprotect.c | 5 ++++- > 2 files changed, 7 insertions(+), 1 deletion(-) Needs an ACK from an mm person.
On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote: > > From: Sean Christopherson <sean.j.christopherson@intel.com> > > Add vm_ops()->mprotect() for additional constraints for a VMA. > > Intel Software Guard eXtensions (SGX) will use this callback to add two > constraints: > > 1. Verify that the address range does not have holes: each page address > must be filled with an enclave page. > 2. Verify that VMA permissions won't surpass the permissions of any enclave > page within the address range. Enclave cryptographically sealed > permissions for each page address that set the upper limit for possible > VMA permissions. Not respecting this can cause #GP's to be emitted. It's been awhile since I looked at this. Can you remind us: is this just preventing userspace from shooting itself in the foot or is this something more important? --Andy
On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote: > On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com> wrote: > > > > From: Sean Christopherson <sean.j.christopherson@intel.com> > > > > Add vm_ops()->mprotect() for additional constraints for a VMA. > > > > Intel Software Guard eXtensions (SGX) will use this callback to add two > > constraints: > > > > 1. Verify that the address range does not have holes: each page address > > must be filled with an enclave page. > > 2. Verify that VMA permissions won't surpass the permissions of any enclave > > page within the address range. Enclave cryptographically sealed > > permissions for each page address that set the upper limit for possible > > VMA permissions. Not respecting this can cause #GP's to be emitted. > > It's been awhile since I looked at this. Can you remind us: is this > just preventing userspace from shooting itself in the foot or is this > something more important? > > --Andy Haitao found this: https://patchwork.kernel.org/patch/10978327/ The way I understand it, for an LSM hook it makes sense that the mprotect() can deduce a single permission for an enclave address range. With those constraints it is possible. /Jarkko
On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote: > On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com> wrote: > > > > From: Sean Christopherson <sean.j.christopherson@intel.com> > > > > Add vm_ops()->mprotect() for additional constraints for a VMA. > > > > Intel Software Guard eXtensions (SGX) will use this callback to add two > > constraints: > > > > 1. Verify that the address range does not have holes: each page address > > must be filled with an enclave page. > > 2. Verify that VMA permissions won't surpass the permissions of any enclave > > page within the address range. Enclave cryptographically sealed > > permissions for each page address that set the upper limit for possible > > VMA permissions. Not respecting this can cause #GP's to be emitted. Side note, #GP is wrong. EPCM violations are #PFs. Skylake CPUs #GP, but that's technically an errata. But this isn't the real motivation, e.g. userspace can already trigger #GP/#PF by reading/writing a bad address, SGX simply adds another flavor. > It's been awhile since I looked at this. Can you remind us: is this > just preventing userspace from shooting itself in the foot or is this > something more important? Something more important, it's used to prevent userspace from circumventing a noexec filesystem by loading code into an enclave, and to give the kernel the option of adding enclave specific LSM policies in the future. The source file (if one exists) for the enclave is long gone when the enclave is actually mmap()'d and mprotect()'d. To enforce noexec, the requested permissions for a given page are snapshotted when the page is added to the enclave, i.e. when the enclave is built. Enclave pages that will be executable must originate from an a MAYEXEC VMA, e.g. the source page can't come from a noexec file system. The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring permissions beyond what are allowed, e.g. trying to map an enclave page with EXEC permissions when the page was added to the enclave without EXEC. Future LSM policies have a similar need due to vm_file always pointing at /dev/sgx/enclave, e.g. policies couldn't be attached to a specific enclave. ->mprotect() again allows enforcing permissions at map time that were checked at enclave build time, e.g. via an LSM hook. Deferring ->mprotect() until LSM support is added (if it ever is) would be problematic due to SGX2. With SGX2, userspace can extend permissions of an enclave page (for the CPU's EPC Map entry, not the kernel's page tables) without bouncing through the kernel. Without ->mprotect () enforcement. userspace could do EADD(RW) -> mprotect(RWX) -> EMODPE(X) to gain W+X. We want to disallow such a flow now, i.e. force userspace to do EADD(RW,X), so that the hypothetical LSM hook would have all information at EADD(), i.e. would be aware of the EXEC permission, without creating divergent behavior based on whether or not an LSM is active.
> On Sep 18, 2020, at 4:53 PM, Sean Christopherson <sean.j.christopherson@intel.com> wrote: > > On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote: >>> On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen >>> <jarkko.sakkinen@linux.intel.com> wrote: >>> >>> From: Sean Christopherson <sean.j.christopherson@intel.com> >>> >>> Add vm_ops()->mprotect() for additional constraints for a VMA. >>> >>> Intel Software Guard eXtensions (SGX) will use this callback to add two >>> constraints: >>> >>> 1. Verify that the address range does not have holes: each page address >>> must be filled with an enclave page. >>> 2. Verify that VMA permissions won't surpass the permissions of any enclave >>> page within the address range. Enclave cryptographically sealed >>> permissions for each page address that set the upper limit for possible >>> VMA permissions. Not respecting this can cause #GP's to be emitted. > > Side note, #GP is wrong. EPCM violations are #PFs. Skylake CPUs #GP, but > that's technically an errata. But this isn't the real motivation, e.g. > userspace can already trigger #GP/#PF by reading/writing a bad address, SGX > simply adds another flavor. > >> It's been awhile since I looked at this. Can you remind us: is this >> just preventing userspace from shooting itself in the foot or is this >> something more important? > > Something more important, it's used to prevent userspace from circumventing > a noexec filesystem by loading code into an enclave, and to give the kernel the > option of adding enclave specific LSM policies in the future. > > The source file (if one exists) for the enclave is long gone when the enclave > is actually mmap()'d and mprotect()'d. To enforce noexec, the requested > permissions for a given page are snapshotted when the page is added to the > enclave, i.e. when the enclave is built. Enclave pages that will be executable > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a > noexec file system. > > The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring > permissions beyond what are allowed, e.g. trying to map an enclave page with > EXEC permissions when the page was added to the enclave without EXEC. > > Future LSM policies have a similar need due to vm_file always pointing at > /dev/sgx/enclave, e.g. policies couldn't be attached to a specific enclave. > ->mprotect() again allows enforcing permissions at map time that were checked > at enclave build time, e.g. via an LSM hook. > > Deferring ->mprotect() until LSM support is added (if it ever is) would be > problematic due to SGX2. With SGX2, userspace can extend permissions of an > enclave page (for the CPU's EPC Map entry, not the kernel's page tables) > without bouncing through the kernel. Without ->mprotect () enforcement. > userspace could do EADD(RW) -> mprotect(RWX) -> EMODPE(X) to gain W+X. We > want to disallow such a flow now, i.e. force userspace to do EADD(RW,X), so > that the hypothetical LSM hook would have all information at EADD(), i.e. > would be aware of the EXEC permission, without creating divergent behavior > based on whether or not an LSM is active. That’s what I thought. Can we get this in the changelog?
On Mon, Sep 21, 2020 at 03:49:56PM +0300, Jarkko Sakkinen wrote:
> What really should be documented is to answer why we consider an enclave
~~
the (editing mistake)
/Jarkko
On Mon, Sep 21, 2020 at 03:49:56PM +0300, Jarkko Sakkinen wrote: > The 2nd part of the answer is the answer to the question: why we want to > feed LSM hooks enclaves exactly in this state. The question can be further refined as why: why this is the best possible set of substates to filter in? "no holes" part is obvious as the consequence of not surpassing permissions of any of the pages in range, as you could otherwise break the state with ioctl(SGX_ENCLAVE_ADD_PAGES) with permssions that are below the mmap permissions. /Jarkko
On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote: > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote: > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote: > > > a noexec filesystem by loading code into an enclave, and to give the kernel the > > > option of adding enclave specific LSM policies in the future. > > > > > > The source file (if one exists) for the enclave is long gone when the enclave > > > is actually mmap()'d and mprotect()'d. To enforce noexec, the requested > > > permissions for a given page are snapshotted when the page is added to the > > > enclave, i.e. when the enclave is built. Enclave pages that will be executable > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a > > > noexec file system. > > > > noexec check is done in __sgx_encl_add_page(), not in this callback. > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the > > addresses, checks that permissions are not surpassed and there are > > no holes. > > Yes, that's what I said. sgx_encl_add_page() will remove such page. The callback does not interact with this process as such pages never get to the enclave. > I would copy-paste the part of the response that was snipped... I do agree with the main conclusions but it contains also things that I do not see relating that much, like noexec partitions. It goes too far in detail what will LSM's end up doing. I absolutely do not want to forecast too far how LSM hooks would work. Since we do not have ioctl's for EMODPE and such, I see EMODPE as the only reason for doing this right now. Otherwise, we are in trouble with any possible LSM callbacks. For any sort of access control decision, things decided must stick. I would add something like this to the commit message largely based on your text: "SGX stores the permissions for each page when they are first added, and will implement this callback to check that mmap() or mprotect() does not surpass these permissions in the requested address range. This is done to prevent using EMODPE upgrading permissions of a page after mmap() or mprotect() has been done, which would prevent any sort of LSM callbacks to be implemented later on because the access control decision could deprecate." /Jarkko
On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote: > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote: > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote: > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote: > > > > a noexec filesystem by loading code into an enclave, and to give the kernel the > > > > option of adding enclave specific LSM policies in the future. > > > > > > > > The source file (if one exists) for the enclave is long gone when the enclave > > > > is actually mmap()'d and mprotect()'d. To enforce noexec, the requested > > > > permissions for a given page are snapshotted when the page is added to the > > > > enclave, i.e. when the enclave is built. Enclave pages that will be executable > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a > > > > noexec file system. > > > > > > noexec check is done in __sgx_encl_add_page(), not in this callback. > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the > > > addresses, checks that permissions are not surpassed and there are > > > no holes. > > > > Yes, that's what I said. > > sgx_encl_add_page() will remove such page. The callback does not > interact with this process as such pages never get to the enclave. I think we're in violent agreement, mostly. Userspace can add the page without EXEC permissions in the EPCM, and thus avoid the noexec/VM_MAYEXEC check. The enclave can then do EMODPE to gain EXEC permissions in the EPMC. Without the ->mprotect() hook, we wouldn't be able to detect/prevent such shenanigans. > > I would copy-paste the part of the response that was snipped... > > I do agree with the main conclusions but it contains also things that I > do not see relating that much, like noexec partitions. As above, this does directly related to noexec/VM_MAYEXEC. > It goes too far in detail what will LSM's end up doing. I absolutely do not > want to forecast too far how LSM hooks would work. That's fine, I was responding to Andy's question, not intending to write a changelog. > Since we do not have ioctl's for EMODPE and such, I see EMODPE as the > only reason for doing this right now. Otherwise, we are in trouble with > any possible LSM callbacks. For any sort of access control decision, > things decided must stick. Yes, again, violent agreement :-). > I would add something like this to the commit message largely based on > your text: > > "SGX stores the permissions for each page when they are first added, and > will implement this callback to check that mmap() or mprotect() does not > surpass these permissions in the requested address range. > > This is done to prevent using EMODPE upgrading permissions of a page > after mmap() or mprotect() has been done, which would prevent any sort > of LSM callbacks to be implemented later on because the access control > decision could deprecate."
On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote: > On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote: > > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote: > > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote: > > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote: > > > > > a noexec filesystem by loading code into an enclave, and to give the kernel the > > > > > option of adding enclave specific LSM policies in the future. > > > > > > > > > > The source file (if one exists) for the enclave is long gone when the enclave > > > > > is actually mmap()'d and mprotect()'d. To enforce noexec, the requested > > > > > permissions for a given page are snapshotted when the page is added to the > > > > > enclave, i.e. when the enclave is built. Enclave pages that will be executable > > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a > > > > > noexec file system. > > > > > > > > noexec check is done in __sgx_encl_add_page(), not in this callback. > > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the > > > > addresses, checks that permissions are not surpassed and there are > > > > no holes. > > > > > > Yes, that's what I said. > > > > sgx_encl_add_page() will remove such page. The callback does not > > interact with this process as such pages never get to the enclave. > > I think we're in violent agreement, mostly. > > Userspace can add the page without EXEC permissions in the EPCM, and thus > avoid the noexec/VM_MAYEXEC check. The enclave can then do EMODPE to gain > EXEC permissions in the EPMC. Without the ->mprotect() hook, we wouldn't > be able to detect/prevent such shenanigans. Right, the VM_MAYEXEC in the code is nested under VM_EXEC check. I'm only wondering why not block noexec completely with any permissions, i.e. why not just have unconditional VM_MAYEXEC check? /Jarkko
On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote: > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote: > > On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote: > > > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote: > > > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote: > > > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote: > > > > > > a noexec filesystem by loading code into an enclave, and to give the kernel the > > > > > > option of adding enclave specific LSM policies in the future. > > > > > > > > > > > > The source file (if one exists) for the enclave is long gone when the enclave > > > > > > is actually mmap()'d and mprotect()'d. To enforce noexec, the requested > > > > > > permissions for a given page are snapshotted when the page is added to the > > > > > > enclave, i.e. when the enclave is built. Enclave pages that will be executable > > > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a > > > > > > noexec file system. > > > > > > > > > > noexec check is done in __sgx_encl_add_page(), not in this callback. > > > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the > > > > > addresses, checks that permissions are not surpassed and there are > > > > > no holes. > > > > > > > > Yes, that's what I said. > > > > > > sgx_encl_add_page() will remove such page. The callback does not > > > interact with this process as such pages never get to the enclave. > > > > I think we're in violent agreement, mostly. > > > > Userspace can add the page without EXEC permissions in the EPCM, and thus > > avoid the noexec/VM_MAYEXEC check. The enclave can then do EMODPE to gain > > EXEC permissions in the EPMC. Without the ->mprotect() hook, we wouldn't > > be able to detect/prevent such shenanigans. > > Right, the VM_MAYEXEC in the code is nested under VM_EXEC check. > > I'm only wondering why not block noexec completely with any permissions, > i.e. why not just have unconditional VM_MAYEXEC check? I.e. why not this: static int __sgx_encl_add_page(struct sgx_encl *encl, struct sgx_encl_page *encl_page, struct sgx_epc_page *epc_page, struct sgx_secinfo *secinfo, unsigned long src) { struct sgx_pageinfo pginfo; struct vm_area_struct *vma; struct page *src_page; int ret; vma = find_vma(current->mm, src); if (!vma) return -EFAULT; if (!(vma->vm_flags & VM_MAYEXEC)) return -EACCES; I'm not seeing the reason for "partial support" for noexec partitions. If there is a good reason, fine, let's just then document it. /Jarkko
On 9/22/20 5:58 AM, Jarkko Sakkinen wrote: > Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs > called enclaves, of which page permissions are defined when the enclave "of which" => "for which" > is first loaded. Once an enclave is loaded and initialized, it can be > mapped to the process address space. Could you compare and contrast this a *bit* with existing executables? What's special about SGX? ELF executables have page permissions inside the binary too. Why don't we use this mechanism for them? > Enclave permissions can be dynamically modified by using ENCLS[EMODPE] I'm not sure this sentence matters. I'm not sure why I care what the instruction is named that does this. But, it _sounds_ here like an enclave can adjust its own permissions directly with ENCLS[EMODPE]. > instruction. We want to limit its use to not allow higher permissions than > the ones defined when the enclave was first created. Rather than higher and lower, please use stronger and weaker. Also, please get rid of the "we". > Add 'mprotect' hook to vm_ops, so that we can implement a callback for SGX > that will check that {mmap, mprotect}() permissions do not surpass any of > the page permissions in the address range defined. "check" => "ensure" > This is required in order to be able to make any access control decisions > when enclave pages are loaded. Now I'm confused. I actually don't think I have a strong understanding of how an enclave actually gets loaded, how mmap() and mprotect() are normally used and what this hook is intended to thwart.
On Tue, Sep 22, 2020 at 08:35:15AM +0300, Jarkko Sakkinen wrote: > On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote: > > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote: > > > Userspace can add the page without EXEC permissions in the EPCM, and thus > > > avoid the noexec/VM_MAYEXEC check. The enclave can then do EMODPE to gain > > > EXEC permissions in the EPMC. Without the ->mprotect() hook, we wouldn't > > > be able to detect/prevent such shenanigans. > > > > Right, the VM_MAYEXEC in the code is nested under VM_EXEC check. > > > > I'm only wondering why not block noexec completely with any permissions, > > i.e. why not just have unconditional VM_MAYEXEC check? > > I.e. why not this: > > static int __sgx_encl_add_page(struct sgx_encl *encl, > struct sgx_encl_page *encl_page, > struct sgx_epc_page *epc_page, > struct sgx_secinfo *secinfo, unsigned long src) > { > struct sgx_pageinfo pginfo; > struct vm_area_struct *vma; > struct page *src_page; > int ret; > > vma = find_vma(current->mm, src); > if (!vma) > return -EFAULT; > > if (!(vma->vm_flags & VM_MAYEXEC)) > return -EACCES; > > I'm not seeing the reason for "partial support" for noexec partitions. > > If there is a good reason, fine, let's just then document it. There are scenarios I can contrive, e.g. loading an enclave from a noexec filesystem without having to copy the entire enclave to anon memory, or loading a data payload from a noexec FS. They're definitely contrived scenarios, but given that we also want the ->mprotect() hook/behavior for potential LSM interaction, supporting said contrived scenarios costs is "free".
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote: > > Enclave permissions can be dynamically modified by using ENCLS[EMODPE] > > I'm not sure this sentence matters. I'm not sure why I care what the > instruction is named that does this. But, it _sounds_ here like an > enclave can adjust its own permissions directly with ENCLS[EMODPE]. If there was no EMODPE, I would drop this patch from the patch set. It is the only reason I keep it. There are no other hard reasons to have this. > Now I'm confused. I actually don't think I have a strong understanding > of how an enclave actually gets loaded, how mmap() and mprotect() are > normally used and what this hook is intended to thwart. Enclave gets loaded with the ioctl API so ATM we rely only on DAC permissions. In future you might want to have LSM hooks to improve granularity in two points: 1. When pages are added using SGX_IOC_ENCLAVE ADD_PAGES. 2. When enclave is initialized using SGX_IOC_ENCLAVE_INIT In both you might want to make a policy decision based on origin and page permissions. If we do not limit mmap(), enclave could later on upgrade its permissions with EMODPE and do mmap(). No matter what kind of LSM hooks or whatever possible improvements are done later on to access control, they won't work unless we have this because the permissions could be different than the original. With this change you can still do EMODPE inside an enclave, but you don't gain anything with it because your max permissions are capped during the build time. I'm not sure what exactly from this is missing from the commit message but if you get this explanation maybe you can help me out with that. Thank you for the feedback. /Jarkko
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote: > On 9/22/20 5:58 AM, Jarkko Sakkinen wrote: > > Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs > > called enclaves, of which page permissions are defined when the enclave > > "of which" => "for which" > > > is first loaded. Once an enclave is loaded and initialized, it can be > > mapped to the process address space. > > Could you compare and contrast this a *bit* with existing executables? > What's special about SGX? ELF executables have page permissions inside > the binary too. Why don't we use this mechanism for them? There is no standard file format for enclaves. They are dynamically built. And the way enclaves are used as part of an app and throwing container inside enclave differ. A single format would no work too well for all possible use cases. I cannot formally prove this of course but it is highly unlikely that we could ever define such a format. Thus, the security focus is allow to verify from origin. And the existing ecosystem around SGX is already too large to suddenly move to a single format. User base, I guess, is also an argument. This is not yet mainline code so technically we have zero ABI debt but I still think this is a valid point because SGX is already widely used. I'm not really sure what would be the best way to nail this information to the commit message but I'll try to figure out something before I send the next version of the patch set. /Jarkko
On Tue, Sep 22, 2020 at 09:43:02AM -0700, Sean Christopherson wrote: > On Tue, Sep 22, 2020 at 08:35:15AM +0300, Jarkko Sakkinen wrote: > > On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote: > > > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote: > > > > Userspace can add the page without EXEC permissions in the EPCM, and thus > > > > avoid the noexec/VM_MAYEXEC check. The enclave can then do EMODPE to gain > > > > EXEC permissions in the EPMC. Without the ->mprotect() hook, we wouldn't > > > > be able to detect/prevent such shenanigans. > > > > > > Right, the VM_MAYEXEC in the code is nested under VM_EXEC check. > > > > > > I'm only wondering why not block noexec completely with any permissions, > > > i.e. why not just have unconditional VM_MAYEXEC check? > > > > I.e. why not this: > > > > static int __sgx_encl_add_page(struct sgx_encl *encl, > > struct sgx_encl_page *encl_page, > > struct sgx_epc_page *epc_page, > > struct sgx_secinfo *secinfo, unsigned long src) > > { > > struct sgx_pageinfo pginfo; > > struct vm_area_struct *vma; > > struct page *src_page; > > int ret; > > > > vma = find_vma(current->mm, src); > > if (!vma) > > return -EFAULT; > > > > if (!(vma->vm_flags & VM_MAYEXEC)) > > return -EACCES; > > > > I'm not seeing the reason for "partial support" for noexec partitions. > > > > If there is a good reason, fine, let's just then document it. > > There are scenarios I can contrive, e.g. loading an enclave from a noexec > filesystem without having to copy the entire enclave to anon memory, or > loading a data payload from a noexec FS. > > They're definitely contrived scenarios, but given that we also want the > ->mprotect() hook/behavior for potential LSM interaction, supporting said > contrived scenarios costs is "free". For me this has caused months of confusion and misunderstanding of this feature. I only recently realized that "oh, right, we invented this". They are contrived scenarios enough that they should be considered when the workloads hit. Either we fully support noexec or not at all. Any "partial" thing is a two edged sword: it can bring some robustness with the price of complexity and possible unknown uknown scenarios where they might become API issue. I rather think later on how to extend API in some way to enable such contrivid scenarios rather than worrying about how this could be abused. The whole SGX is complex beast already so lets not add any extra when there is no a hard requirement to do so. I'll categorically deny noexec in the next patch set version. /Jarkko
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote: > Now I'm confused. I actually don't think I have a strong understanding > of how an enclave actually gets loaded, how mmap() and mprotect() are > normally used and what this hook is intended to thwart. You saw my other comments. I scraped this together based on your feedback and my responses: " mm: Add 'mprotect' callback to vm_ops Intel Sofware Guard eXtensions (SGX) allows creation of blobs called enclaves, for which page permissions are defined when the enclave is first loaded. Once an enclave is loaded and initialized, it can be mapped to the process address space. There is no standard file format for enclaves. They are dynamically built and the ways how enclaves are deployed differ greatly. For an app you might want to have a simple static binary, but on the other hand for a container you might want to dynamically create the whole thing at run-time. Also, the existing ecosystem for SGX is already large, which would make the task very hard. Finally, even if there was a standard format, one would still want a dynamic way to add pages to the enclave. One big reason for this is that enclaves have load time defined pages that represent entry points to the enclave. Each entry point can service one hardware thread at a time and you might want to run-time parametrize this depending on your environment. The consequence is that enclaves are best created with an ioctl API and the access control can be based only to the origin of the source file for the enclave data, i.e. on VMA file pointer and page permissions. For example, this could be done with LSM hooks that are triggered in the appropriate ioctl's and they could make the access control decision based on this information. Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to upgrade its permissions. If we do not limit mmap() and mprotect(), enclave could upgrade its permissions by using EMODPE followed by an appropriate mprotect() call. This would be completely hidden from the kernel. Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX that will ensure that {mmap, mprotect}() permissions do not surpass any of the original page permissions. This feature allows to maintain and refine sane access control for enclaves. " /Jarkko
On 9/23/20 7:33 AM, Jarkko Sakkinen wrote: > The consequence is that enclaves are best created with an ioctl API and the > access control can be based only to the origin of the source file for the > enclave data, i.e. on VMA file pointer and page permissions. For example, > this could be done with LSM hooks that are triggered in the appropriate > ioctl's and they could make the access control decision based on this > information. > > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave > could upgrade its permissions by using EMODPE followed by an appropriate > mprotect() call. This would be completely hidden from the kernel. > > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX > that will ensure that {mmap, mprotect}() permissions do not surpass any of > the original page permissions. This feature allows to maintain and refine > sane access control for enclaves. Maybe I'm just being dense, but I still don't have a clear idea what function this hook serves. I understand that SGX has an orthogonal set of page permissions to the normal x86 page tables. It needs these so that the OS can't play nasty tricks on the enclave, like removing read-only protections that provide hardening. But, I still don't get the connection to mprotect() and the x86 paging permissions. If the enclave's permissions are orthogonal, then why bother with this hook? Why does the OS view of the enclave's memory matter?
On Thu, Sep 24, 2020 at 07:50:15AM -0700, Dave Hansen wrote: > On 9/23/20 7:33 AM, Jarkko Sakkinen wrote: > > The consequence is that enclaves are best created with an ioctl API and the > > access control can be based only to the origin of the source file for the > > enclave data, i.e. on VMA file pointer and page permissions. For example, > > this could be done with LSM hooks that are triggered in the appropriate > > ioctl's and they could make the access control decision based on this > > information. > > > > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to > > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave > > could upgrade its permissions by using EMODPE followed by an appropriate > > mprotect() call. This would be completely hidden from the kernel. > > > > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX > > that will ensure that {mmap, mprotect}() permissions do not surpass any of > > the original page permissions. This feature allows to maintain and refine > > sane access control for enclaves. > > Maybe I'm just being dense, but I still don't have a clear idea what > function this hook serves. > > I understand that SGX has an orthogonal set of page permissions to the > normal x86 page tables. It needs these so that the OS can't play nasty > tricks on the enclave, like removing read-only protections that provide > hardening. > > But, I still don't get the connection to mprotect() and the x86 paging > permissions. If the enclave's permissions are orthogonal, then why > bother with this hook? Why does the OS view of the enclave's memory matter? For the purpose of this discussion, ignore the enclave permissions. The only reason they're mentioned is to explain the background (well, try to) of how we ended up at an ->mprotect() hook. There was a great deal of discussion in the past about whether or not we could use enclave permissions to enforce OS permissions. The TL:DR version is that because of ENCLU[EMODPE], the answer is "no". What we're preventing via ->mprotect() is using SGX to bypass existing restrictions on code execution, e.g. noexec and LSM policies. Because code must first be loaded into an enclave before it can be executed, all enclaves are kind of a variant on (in SELinux terminology) either EXECMOD or EXECMEM. I.e. it's simply not possible to execute an enclave by mapping the source file as executable. This effectively allows userspace to bypass a noexec FS by loading code into an enclave without EXEC perms on the source file, only on /dev/sgx/enclave, and denying EXEC on /dev/sgx/enclave would prevent running _any_ enclave. The ->mprotect() hook is used by SGX to require userspace to declare what permissions are allowed on any given enclave page, e.g. SGX's mmap()/mprotect() requires all underlying enclave pages to be declared as executable if the mmap()/mprotect() is specifying VM_EXEC. By requiring userspace to declare their intent up front, SGX can then enforce noexec by requiring pages that are declared as executable to have VM_MAYEXEC set in the source VMA when loading code into the enclave. As Jarkko pointed out, an alternative to adding ->mprotect() would be to simply require VM_MAYEXEC on _all_ source VMAs when loading code into the enclave. That would work, albeit with the potentially undesirable side effect of preventing loading any part of an enclave from e.g. a noexec, readonly FS. But, unconditionally requiring VM_MAYEXEC doesn't address the Linux Security Module hooks for mmap() and mprotect(), which could also be bypassed by abusing SGX. E.g. a process could gain arbitrary code execution by loading code from anonymous memory into an enclave, as the LSM checks hooks at mmap()/mprotect() will see always vm_file=/dev/sgx/enclave. An LSM could deny a process access to /dev/sgx/enclave, but again that is very coarse granularity. By requiring userspace to declare permissions up front (when loading code/data into an enclave), SGX can make explicit upcalls to LSMs hooks at load time so that an LSM can enforce a meaningful policy, e.g. require all enclave code to originate from an executable file system. This series doesn't actually implement the LSM integration, but it does ensure that _if_ we want to add LSM support in the future, we can do so without breaking userspace.
On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote: > On Tue, Sep 22, 2020 at 09:43:02AM -0700, Sean Christopherson wrote: >> On Tue, Sep 22, 2020 at 08:35:15AM +0300, Jarkko Sakkinen wrote: >> > On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote: >> > > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote: >> > > > Userspace can add the page without EXEC permissions in the EPCM, >> and thus >> > > > avoid the noexec/VM_MAYEXEC check. The enclave can then do >> EMODPE to gain >> > > > EXEC permissions in the EPMC. Without the ->mprotect() hook, we >> wouldn't >> > > > be able to detect/prevent such shenanigans. >> > > >> > > Right, the VM_MAYEXEC in the code is nested under VM_EXEC check. >> > > >> > > I'm only wondering why not block noexec completely with any >> permissions, >> > > i.e. why not just have unconditional VM_MAYEXEC check? >> > >> > I.e. why not this: >> > >> > static int __sgx_encl_add_page(struct sgx_encl *encl, >> > struct sgx_encl_page *encl_page, >> > struct sgx_epc_page *epc_page, >> > struct sgx_secinfo *secinfo, unsigned long src) >> > { >> > struct sgx_pageinfo pginfo; >> > struct vm_area_struct *vma; >> > struct page *src_page; >> > int ret; >> > >> > vma = find_vma(current->mm, src); >> > if (!vma) >> > return -EFAULT; >> > >> > if (!(vma->vm_flags & VM_MAYEXEC)) >> > return -EACCES; >> > >> > I'm not seeing the reason for "partial support" for noexec partitions. >> > >> > If there is a good reason, fine, let's just then document it. >> >> There are scenarios I can contrive, e.g. loading an enclave from a >> noexec >> filesystem without having to copy the entire enclave to anon memory, or >> loading a data payload from a noexec FS. >> >> They're definitely contrived scenarios, but given that we also want the >> ->mprotect() hook/behavior for potential LSM interaction, supporting >> said >> contrived scenarios costs is "free". > > For me this has caused months of confusion and misunderstanding of this > feature. I only recently realized that "oh, right, we invented this". > > They are contrived scenarios enough that they should be considered when > the workloads hit. > > Either we fully support noexec or not at all. Any "partial" thing is a > two edged sword: it can bring some robustness with the price of > complexity and possible unknown uknown scenarios where they might become > API issue. > > I rather think later on how to extend API in some way to enable such > contrivid scenarios rather than worrying about how this could be abused. > > The whole SGX is complex beast already so lets not add any extra when > there is no a hard requirement to do so. > > I'll categorically deny noexec in the next patch set version. > > /Jarkko There are use cases supported currently in which enclave binary is received via IPC/RPC and held in buffers before EADD. Denying noexec altogether would break those, right?
On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote: > On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com> wrote: > >I'll categorically deny noexec in the next patch set version. > > > >/Jarkko > > There are use cases supported currently in which enclave binary is received > via IPC/RPC and held in buffers before EADD. Denying noexec altogether would > break those, right? No. noexec only applies to file-backed VMAs, what you're describing is loading an enclave from an anon VMA, which will still have VM_MAYEXEC. I believe you're thinking of SELinux's EXECMEM, which is required to execute from anonymous memory, and which we talked about (more than once) applying to SGX enclaves. That being said, I still dislike the idea of requiring VM_MAYEXEC, it's a hack that doesn't really buy us much, if anything.
On 9/24/20 12:28 PM, Sean Christopherson wrote: > On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote: >> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen >> <jarkko.sakkinen@linux.intel.com> wrote: >>> I'll categorically deny noexec in the next patch set version. >>> >>> /Jarkko >> There are use cases supported currently in which enclave binary is received >> via IPC/RPC and held in buffers before EADD. Denying noexec altogether would >> break those, right? > No. noexec only applies to file-backed VMAs, what you're describing is loading > an enclave from an anon VMA, which will still have VM_MAYEXEC. Maybe I'm just stupid, but I still don't get the scenario that's being thwarted or why it is valuable. The SDM is worthless on what EMODPE does or what its restrictions are. In pseudo-C, it's something logically like this for the "nice" case: ptr = mmap("/some/executable", PROT_EXEC); ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); mmap(sgx_fd); EENTER; And we're trying to thwart: ptr = mmap("/mnt/noexec/file", PROT_READ); ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); mmap(sgx_fd); EENTER; because that loads data into the enclave which is executable but which was not executable normally. But, we're allowing this from anonymous memory, so this would seem to work: ptr = mmap("/mnt/noexec/file", PROT_READ); buffer = malloc(PAGE_SIZE); memcpy(buffer, ptr, PAGE_SIZE); // need mprotect(buf, PROT_EXEC)??? ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size); mmap(sgx_fd); EENTER; and give the same result. What am I missing?
On Thu, Sep 24, 2020 at 12:39:24PM -0700, Dave Hansen wrote: > On 9/24/20 12:28 PM, Sean Christopherson wrote: > > On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote: > >> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen > >> <jarkko.sakkinen@linux.intel.com> wrote: > >>> I'll categorically deny noexec in the next patch set version. > >>> > >>> /Jarkko > >> There are use cases supported currently in which enclave binary is received > >> via IPC/RPC and held in buffers before EADD. Denying noexec altogether would > >> break those, right? > > No. noexec only applies to file-backed VMAs, what you're describing is loading > > an enclave from an anon VMA, which will still have VM_MAYEXEC. > > Maybe I'm just stupid, but I still don't get the scenario that's being > thwarted or why it is valuable. The SDM is worthless on what EMODPE > does or what its restrictions are. > > In pseudo-C, it's something logically like this for the "nice" case: > > ptr = mmap("/some/executable", PROT_EXEC); > ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); > mmap(sgx_fd); > EENTER; > > And we're trying to thwart: > > ptr = mmap("/mnt/noexec/file", PROT_READ); > ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); > mmap(sgx_fd); > EENTER; > > because that loads data into the enclave which is executable but which > was not executable normally. But, we're allowing this from anonymous > memory, so this would seem to work: > > ptr = mmap("/mnt/noexec/file", PROT_READ); > buffer = malloc(PAGE_SIZE); > memcpy(buffer, ptr, PAGE_SIZE); > // need mprotect(buf, PROT_EXEC)??? > ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size); > mmap(sgx_fd); > EENTER; > > and give the same result. What am I missing? The last example, where the enclave is copied to a buffer, is out of scope for noexec. But, it is in scope for LSMs, e.g. for this last example, we could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an SGX specific equivalent). The ->mprotect() hook gives us direct line of sight to such LSM upcalls, e.g. I have fully working code that implements the LSM integration. LSM support isn't in this series because the only thing everyone could agree on in terms of an LSM implementation is that it wasn't needed for initial upstreaming :-)
On 9/24/20 1:01 PM, Sean Christopherson wrote: >> In pseudo-C, it's something logically like this for the "nice" case: >> >> ptr = mmap("/some/executable", PROT_EXEC); >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); >> mmap(sgx_fd); >> EENTER; >> >> And we're trying to thwart: >> >> ptr = mmap("/mnt/noexec/file", PROT_READ); >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); >> mmap(sgx_fd); >> EENTER; >> >> because that loads data into the enclave which is executable but which >> was not executable normally. But, we're allowing this from anonymous >> memory, so this would seem to work: >> >> ptr = mmap("/mnt/noexec/file", PROT_READ); >> buffer = malloc(PAGE_SIZE); >> memcpy(buffer, ptr, PAGE_SIZE); >> // need mprotect(buf, PROT_EXEC)??? >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size); >> mmap(sgx_fd); >> EENTER; >> >> and give the same result. What am I missing? > The last example, where the enclave is copied to a buffer, is out of scope > for noexec. But, it is in scope for LSMs, e.g. for this last example, we > could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an > SGX specific equivalent). Why don't we just declare enclave memory as "out of scope for noexec" in the same way that anonymous memory is, and just discard this patch? That doesn't seem too much of a stretch.
On Thu, Sep 24, 2020 at 01:10:31PM -0700, Dave Hansen wrote: > On 9/24/20 1:01 PM, Sean Christopherson wrote: > >> In pseudo-C, it's something logically like this for the "nice" case: > >> > >> ptr = mmap("/some/executable", PROT_EXEC); > >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); > >> mmap(sgx_fd); > >> EENTER; > >> > >> And we're trying to thwart: > >> > >> ptr = mmap("/mnt/noexec/file", PROT_READ); > >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); > >> mmap(sgx_fd); > >> EENTER; > >> > >> because that loads data into the enclave which is executable but which > >> was not executable normally. But, we're allowing this from anonymous > >> memory, so this would seem to work: > >> > >> ptr = mmap("/mnt/noexec/file", PROT_READ); > >> buffer = malloc(PAGE_SIZE); > >> memcpy(buffer, ptr, PAGE_SIZE); > >> // need mprotect(buf, PROT_EXEC)??? > >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size); > >> mmap(sgx_fd); > >> EENTER; > >> > >> and give the same result. What am I missing? > > The last example, where the enclave is copied to a buffer, is out of scope > > for noexec. But, it is in scope for LSMs, e.g. for this last example, we > > could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an > > SGX specific equivalent). > > Why don't we just declare enclave memory as "out of scope for noexec" in > the same way that anonymous memory is, and just discard this patch? > That doesn't seem too much of a stretch. Because we lose line of sight to LSM support. Without enforcing "declare perms at load time" in the initial series, we would create an ABI where userspace could load an enclave page with only READ permissions and then map the enclave with whatever permissions it wants, without any convenient way for SGX to call into the LSM. Retroactively enforcing permissions at load time would break the ABI, or at least yield different behavior based on the mere existence of LSMs, e.g. if LSMs are supported, suddenly the ADD_PAGES w/ READ -> mmap(RWX) flow breaks, even if there is no LSM policy denying that behavior. Enforcing LSM policies using the existing mmap()/mprotect() hooks doesn't work well because the only information available is a fd pointing at /dev/sgx/enclave, which is largely useless because /dev/sgx/enclave must be map SHARED w/ RWX to run an enclave. We explored things like grabbing a reference to the source file for later verification, but that means pinning files for the entire lifetime of an enclave. Enforcing noexec was an easy/obvious addition since we need 99% of the code for potential LSM support anyways.
On 9/24/20 1:25 PM, Sean Christopherson wrote: ... >> Why don't we just declare enclave memory as "out of scope for noexec" in >> the same way that anonymous memory is, and just discard this patch? >> That doesn't seem too much of a stretch. > > Because we lose line of sight to LSM support. Without enforcing "declare perms > at load time" in the initial series, we would create an ABI where userspace > could load an enclave page with only READ permissions and then map the enclave > with whatever permissions it wants, without any convenient way for SGX to call > into the LSM. This argument holds no water for me. LSMs are all about taking what would otherwise be perfectly acceptable behavior and breaking them in the name of security. They fundamentally break applications that used to work just fine and also did totally sane things. > Retroactively enforcing permissions at load time would break the ABI, or at > least yield different behavior based on the mere existence of LSMs, e.g. if > LSMs are supported, suddenly the ADD_PAGES w/ READ -> mmap(RWX) flow breaks, > even if there is no LSM policy denying that behavior. I'm a security dummy. All I know is that when I see something like this: if (security_vm_enough_memory_mm(mm, grow)) ... I know to ignore it because I like my systems to boot and I'm not using those hooks. :) How could the mere presence of an LSM change the behavior of one of these hooks? Don't they have to actually hook into the specific place and actively go trying to change the behavior at that site?
On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote: > > For me this has caused months of confusion and misunderstanding of this > > feature. I only recently realized that "oh, right, we invented this". > > > > They are contrived scenarios enough that they should be considered when > > the workloads hit. > > > > Either we fully support noexec or not at all. Any "partial" thing is a > > two edged sword: it can bring some robustness with the price of > > complexity and possible unknown uknown scenarios where they might become > > API issue. > > > > I rather think later on how to extend API in some way to enable such > > contrivid scenarios rather than worrying about how this could be abused. > > > > The whole SGX is complex beast already so lets not add any extra when > > there is no a hard requirement to do so. > > > > I'll categorically deny noexec in the next patch set version. > > > > /Jarkko > > There are use cases supported currently in which enclave binary is received > via IPC/RPC and held in buffers before EADD. Denying noexec altogether would > break those, right? I do not see why data cannot be provided at run-time. AFAIK, it is not different from executables how this works when it comes to noexec. /Jarkko
On Thu, Sep 24, 2020 at 12:28:54PM -0700, Sean Christopherson wrote: > On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote: > > On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen > > <jarkko.sakkinen@linux.intel.com> wrote: > > >I'll categorically deny noexec in the next patch set version. > > > > > >/Jarkko > > > > There are use cases supported currently in which enclave binary is received > > via IPC/RPC and held in buffers before EADD. Denying noexec altogether would > > break those, right? > > No. noexec only applies to file-backed VMAs, what you're describing is loading > an enclave from an anon VMA, which will still have VM_MAYEXEC. > > I believe you're thinking of SELinux's EXECMEM, which is required to execute > from anonymous memory, and which we talked about (more than once) applying to > SGX enclaves. > > That being said, I still dislike the idea of requiring VM_MAYEXEC, it's a hack > that doesn't really buy us much, if anything. I think it makes sense as long as it is not half-way there solution. Either require it for the full binary or not at all. I'm fine with either. /Jarkko
On Thu, Sep 24, 2020 at 01:10:31PM -0700, Dave Hansen wrote: > On 9/24/20 1:01 PM, Sean Christopherson wrote: > >> In pseudo-C, it's something logically like this for the "nice" case: > >> > >> ptr = mmap("/some/executable", PROT_EXEC); > >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); > >> mmap(sgx_fd); > >> EENTER; > >> > >> And we're trying to thwart: > >> > >> ptr = mmap("/mnt/noexec/file", PROT_READ); > >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); > >> mmap(sgx_fd); > >> EENTER; > >> > >> because that loads data into the enclave which is executable but which > >> was not executable normally. But, we're allowing this from anonymous > >> memory, so this would seem to work: > >> > >> ptr = mmap("/mnt/noexec/file", PROT_READ); > >> buffer = malloc(PAGE_SIZE); > >> memcpy(buffer, ptr, PAGE_SIZE); > >> // need mprotect(buf, PROT_EXEC)??? > >> ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size); > >> mmap(sgx_fd); > >> EENTER; > >> > >> and give the same result. What am I missing? > > The last example, where the enclave is copied to a buffer, is out of scope > > for noexec. But, it is in scope for LSMs, e.g. for this last example, we > > could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an > > SGX specific equivalent). > > Why don't we just declare enclave memory as "out of scope for noexec" in > the same way that anonymous memory is, and just discard this patch? > That doesn't seem too much of a stretch. I did that already for v39. It unconditionally discards noexec partitions. I see EMODPE as the key driver for this patch, not noexec partitions. I.e. post you've done SGX_IOC_ENCLAVE_INIT you are capped when it comes to permissions. /Jarkko
On Thu, Sep 24, 2020 at 01:54:09PM -0700, Dave Hansen wrote: > On 9/24/20 1:25 PM, Sean Christopherson wrote: > ... > >> Why don't we just declare enclave memory as "out of scope for noexec" in > >> the same way that anonymous memory is, and just discard this patch? > >> That doesn't seem too much of a stretch. > > > > Because we lose line of sight to LSM support. Without enforcing "declare perms > > at load time" in the initial series, we would create an ABI where userspace > > could load an enclave page with only READ permissions and then map the enclave > > with whatever permissions it wants, without any convenient way for SGX to call > > into the LSM. > > This argument holds no water for me. LSMs are all about taking what > would otherwise be perfectly acceptable behavior and breaking them in > the name of security. They fundamentally break applications that used > to work just fine and also did totally sane things. It's not about LSMs breaking things, they can obviously do that without any help. The concern is that, unless we lay the groundwork now, adding support for LSMs in the future will break existing applications or create an unholy mess of an ABI. If we want to support LSM policy for enclave page permissions, checking LSM policies at load time and hooking mprotect() to enforce the policy at run time is by far the cleanest solution of the many ideas we discussed. The problem is that enforcing permissions via mprotect() needs to be done unconditionally, otherwise we end up with weird behavior where the existence of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX policy whatsover. And on the flip side, enforcing permissions unconditionally will break backwards compatibility. I'm a-ok if we want to kill off the ->mprotect() hook, so long as we acknowledge that in doing so we are likely throwing in the towel on supporting LSM policies for enclave page permissions.
On 9/24/20 4:05 PM, Sean Christopherson wrote: > The problem is that enforcing permissions via mprotect() needs to be done > unconditionally, otherwise we end up with weird behavior where the existence > of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX > policy whatsover. Could we make this a bit less abstract, please? Could someone point to code or another examples that demonstrates how the mere existence of an LSM will change what is/isn't allowed? I can't seem to wrap my head around it as-is.
On Thu, Sep 24, 2020 at 04:09:25PM -0700, Dave Hansen wrote: > On 9/24/20 4:05 PM, Sean Christopherson wrote: > > The problem is that enforcing permissions via mprotect() needs to be done > > unconditionally, otherwise we end up with weird behavior where the existence > > of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX > > policy whatsover. > > Could we make this a bit less abstract, please? > > Could someone point to code or another examples that demonstrates how > the mere existence of an LSM will change what is/isn't allowed? > > I can't seem to wrap my head around it as-is. Without pre-declared permissions, loading and running an enclave would be: ptr = malloc(size); memcpy(ptr, evil_shenanigans, size); ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size); ... ioctl(sgx_fd, ENCLAVE_INIT); enclave = mmap(sgx_fd, ... PROT_READ); mprotect(enclave, ..., PROT_READ | PROT_EXEC); EENTER; With the existing security_file_mprotect(), an LSM will see: vma->vm_file ~= /dev/sgx/enclave prot = PROT_READ | PROT_EXEC From a policy perspective, the LSM can't do much because every enclave is backed by /dev/sgx/enclave, and all enclaves need READ and EXEC perms, i.e. a policy can only deny all enclaves or allow enclaves. The solution we came up with is to require userspace to declare the intended permissions at build time so that an LSM hook can be invoked when the source VMA is availble, e.g. in this example, the LSM would see that the process is loading executable code into an enclave from an anonymous VMA: ptr = malloc(size); memcpy(ptr, evil_shenanigans, size); ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size); { ret = security_enclave_load(ptr, prot); if (ret) return ret; enclave_page->declared_prot = prot; } ... ioctl(sgx_fd, ENCLAVE_INIT); and then enforce the declared perms via ->mprotect() enclave = mmap(sgx_fd, ... PROT_READ); mprotect(enclave, ..., PROT_READ | PROT_EXEC); | -> sgx_mprotect(...) { if (~enclave_page->declared_prot & prot) return -EACCES; } EENTER; So the above would be allowed, but this would fail (irrespective of LSM behavior): ptr = malloc(size); memcpy(ptr, evil_shenanigans, size); ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ, ptr, size); ... ioctl(sgx_fd, ENCLAVE_INIT); enclave = mmap(sgx_fd, ... PROT_READ); mprotect(enclave, ..., PROT_READ | PROT_EXEC); My concern is that if we merge this ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size); without ->mprotect(), we can't actually enforce the declared protections. And if we drop the field altogether: ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size); then we can't implement security_enclave_load().
Thanks for the walkthrough. The thing that clicked for me seeing those examples was how the earlier ioctl(ADD_PAGE) is "bound" to later enforcement actions at enclave PTE creation time. On 9/24/20 5:00 PM, Sean Christopherson wrote: > My concern is that if we merge this > > ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size); > > without ->mprotect(), we can't actually enforce the declared protections. And > if we drop the field altogether: > > ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size); > > then we can't implement security_enclave_load(). To me, it's perfectly OK to have parts of the ABI which are unused. It sure makes them harder to test if there are no actual users in the code, but if it solves a real problem with the ABI, I'm fine with it. Let's see if I can put all the pieces together. Background: 1. SGX enclave pages are populated with data by copying data to them from normal memory via: ioctl(sgx_fd, ENCLAVE_ADD_PAGE, src_ptr...); 2. We want to be able to restrict those normal memory data sources. For instance, before copying data to an executable enclave page, we might ensure that the source is executable. 3. Enclave page permissions are dynamic just like normal permissions and can be adjusted at runtime with mprotect() (along with a corresponding special instruction inside the enclave) 4. The original data source may have have long since vanished at the time when enclave page permission are established (mmap() or mprotect()) Solution: The solution is to force enclaves creators to declare their intent up front to ioctl(ENCLAVE_ADD_PAGE). This intent can me immediately compared to the source data mapping (and rejected if necessary). It is also stashed off and then later compared with enclave PTEs to ensure that any future mmap()/mprotect() operations performed by the enclave creator or the enclave itself are consistent with the earlier declared permissions. Essentially, this means that whenever the kernel is asked to change an enclave PTE, it needs to ensure the change is consistent with that stashed intent. There is an existing vm_ops->mmap() hook which allows SGX to do that for mmap(). However, there is no ->mprotect() hook. Add a vm_ops->mprotect() hook so that mprotect() operations which are inconsistent with any page's stashed intent can be rejected by the driver. Implications: However, there is currently no implementation of the intent checks at the time of ioctl(ENCLAVE_ADD_PAGE). That means that the intent argument (SGX_PROT_*) is currently unused. -- Is that all correct? Did I miss anything?
On Fri, Sep 25, 2020 at 10:18:28AM -0700, Dave Hansen wrote: > Thanks for the walkthrough. The thing that clicked for me seeing those > examples was how the earlier ioctl(ADD_PAGE) is "bound" to later > enforcement actions at enclave PTE creation time. > > On 9/24/20 5:00 PM, Sean Christopherson wrote: > > My concern is that if we merge this > > > > ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size); > > > > without ->mprotect(), we can't actually enforce the declared protections. And > > if we drop the field altogether: > > > > ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size); > > > > then we can't implement security_enclave_load(). > > To me, it's perfectly OK to have parts of the ABI which are unused. It > sure makes them harder to test if there are no actual users in the code, > but if it solves a real problem with the ABI, I'm fine with it. > > Let's see if I can put all the pieces together. > > Background: > > 1. SGX enclave pages are populated with data by copying data to them > from normal memory via: ioctl(sgx_fd, ENCLAVE_ADD_PAGE, src_ptr...); > 2. We want to be able to restrict those normal memory data sources. For > instance, before copying data to an executable enclave page, we might > ensure that the source is executable. > 3. Enclave page permissions are dynamic just like normal permissions and > can be adjusted at runtime with mprotect() (along with a > corresponding special instruction inside the enclave) > 4. The original data source may have have long since vanished at the > time when enclave page permission are established (mmap() or > mprotect()) > > Solution: > > The solution is to force enclaves creators to declare their intent up > front to ioctl(ENCLAVE_ADD_PAGE). This intent can me immediately > compared to the source data mapping (and rejected if necessary). It is > also stashed off and then later compared with enclave PTEs to ensure > that any future mmap()/mprotect() operations performed by the enclave > creator or the enclave itself are consistent with the earlier declared > permissions. > > Essentially, this means that whenever the kernel is asked to change an > enclave PTE, it needs to ensure the change is consistent with that > stashed intent. There is an existing vm_ops->mmap() hook which allows > SGX to do that for mmap(). However, there is no ->mprotect() hook. Add > a vm_ops->mprotect() hook so that mprotect() operations which are > inconsistent with any page's stashed intent can be rejected by the driver. Yes to all of the above. > Implications: > > However, there is currently no implementation of the intent checks at > the time of ioctl(ENCLAVE_ADD_PAGE). Correct. > That means that the intent argument (SGX_PROT_*) is currently unused. No, the intent argument is used (eventually) by SGX's ->mprotect() implementation, i.e. sgx_mprotect() enforces that the actual protections are a subset of the declared/intended protections. If ->mprotect() is not merged, then it yes, it will be unused. And therein lies the problem as the kernel can't start using/enforcing the intent without breaking userspace. E.g. an enclave loaded with SGX_PROT_READ but mprotect()'d with PROT_READ | PROT_EXEC would break if sgx_mprotect() came along. One way to avoid introducing ->mprotect() would be to require all enclaves to declare all pages with READ|WRITE|EXEC. Then we could drop sgx_mprotect() since the mprotect() permissions are guaranteed to be a subset of the declared permissions. That would have the added bonus of eliminating the per-page checks in sgx_mmap()/sgx_mprotect(), though I've no idea if that is a meaningful optmization or it's lost in the noise. The big downside of requiring READ|WRITE|EXEC is that it will make life hell for a LSM policy owner if they ever want to apply EXECMEM or EXECMOD style restritions on enclaves, i.e. if SELinux folks want to add security_enclave_load(). I find that I'm more or less ok with that approach, in no small part because introducing security_enclave_load() might be a pretty big "if", e.g. security folks may decide that they'd rather allow/deny enclaves based on the measurement or signer of the enclave and eschew per-page checks entirely. > -- > > Is that all correct? Did I miss anything?
On 9/25/20 12:43 PM, Sean Christopherson wrote: >> That means that the intent argument (SGX_PROT_*) is currently unused. > No, the intent argument is used (eventually) by SGX's ->mprotect() > implementation, i.e. sgx_mprotect() enforces that the actual protections are a > subset of the declared/intended protections. > > If ->mprotect() is not merged, then it yes, it will be unused. OK, I think I've got it. I think I'm OK with adding ->mprotect(). As long as folks buy into the argument that intent needs to be checked at mmap() time, they obviously need to be checked at mprotect() too. Jarkko, if you want to try and rewrite the changelog, capturing the discussion here and reply, I think I can ack the resulting patch. I don't know if that will satisfy the request from Boris from an ack from a "mm person", but we can at least start there. :) Please be judicious in what you include in the changelog. There's been a lot of detritus in them. Let's keep it as short, sweet, simple and on topic as we can.
> On Sep 25, 2020, at 12:53 PM, Dave Hansen <dave.hansen@intel.com> wrote: > > On 9/25/20 12:43 PM, Sean Christopherson wrote: >>> That means that the intent argument (SGX_PROT_*) is currently unused. >> No, the intent argument is used (eventually) by SGX's ->mprotect() >> implementation, i.e. sgx_mprotect() enforces that the actual protections are a >> subset of the declared/intended protections. >> >> If ->mprotect() is not merged, then it yes, it will be unused. > > OK, I think I've got it. > > I think I'm OK with adding ->mprotect(). As long as folks buy into the > argument that intent needs to be checked at mmap() time, they obviously > need to be checked at mprotect() too. > > Jarkko, if you want to try and rewrite the changelog, capturing the > discussion here and reply, I think I can ack the resulting patch. I > don't know if that will satisfy the request from Boris from an ack from > a "mm person", but we can at least start there. :) I think I agree. ->mprotect seems reasonable to me. FWIW, I don’t think I should ack this particular thing — it was, to a decent extent, my suggestion in the first place, so I’m biased. I think it turned into something reasonable, and the ->mprotect mechanism seems easily supportable and plausibly useful for other purposes down the road. > > Please be judicious in what you include in the changelog. There's been > a lot of detritus in them. Let's keep it as short, sweet, simple and on > topic as we can.
On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote: > On 9/25/20 12:43 PM, Sean Christopherson wrote: > >> That means that the intent argument (SGX_PROT_*) is currently unused. > > No, the intent argument is used (eventually) by SGX's ->mprotect() > > implementation, i.e. sgx_mprotect() enforces that the actual protections are a > > subset of the declared/intended protections. > > > > If ->mprotect() is not merged, then it yes, it will be unused. > > OK, I think I've got it. > > I think I'm OK with adding ->mprotect(). As long as folks buy into the > argument that intent needs to be checked at mmap() time, they obviously > need to be checked at mprotect() too. > > Jarkko, if you want to try and rewrite the changelog, capturing the > discussion here and reply, I think I can ack the resulting patch. I > don't know if that will satisfy the request from Boris from an ack from > a "mm person", but we can at least start there. :) I think what it needs, based on what I've read, is the step by step description of the EMODPE scenarion without this callback and with it. I think other important thing to underline is that an LSM or any other security measure can only do a sane decision when the enclave is loaded. At that point we know the source (vm_file). I.e. when you are doing mmap() or mprotect() you don't have that information. The permissions kind of describe the contact made at that point of time. > Please be judicious in what you include in the changelog. There's been > a lot of detritus in them. Let's keep it as short, sweet, simple and on > topic as we can. Of course. /Jarkko
On 9/27/20 5:53 PM, Jarkko Sakkinen wrote: > On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote: >> On 9/25/20 12:43 PM, Sean Christopherson wrote: >>>> That means that the intent argument (SGX_PROT_*) is currently unused. >>> No, the intent argument is used (eventually) by SGX's ->mprotect() >>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a >>> subset of the declared/intended protections. >>> >>> If ->mprotect() is not merged, then it yes, it will be unused. >> >> OK, I think I've got it. >> >> I think I'm OK with adding ->mprotect(). As long as folks buy into the >> argument that intent needs to be checked at mmap() time, they obviously >> need to be checked at mprotect() too. >> >> Jarkko, if you want to try and rewrite the changelog, capturing the >> discussion here and reply, I think I can ack the resulting patch. I >> don't know if that will satisfy the request from Boris from an ack from >> a "mm person", but we can at least start there. :) > > I think what it needs, based on what I've read, is the step by step > description of the EMODPE scenarion without this callback and with it. EMODPE is virtually irrelevant for this whole thing. The x86 PTE permissions still specify the most restrictive permissions, which is what matters the most. We care about the _worst_ the enclave can do, not what it imposes on itself on top of that. > I think other important thing to underline is that an LSM or any other > security measure can only do a sane decision when the enclave is loaded. > At that point we know the source (vm_file). Right, you know the source, but it can be anonymous or a file.
On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote: > On 9/27/20 5:53 PM, Jarkko Sakkinen wrote: > > On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote: > >> On 9/25/20 12:43 PM, Sean Christopherson wrote: > >>>> That means that the intent argument (SGX_PROT_*) is currently unused. > >>> No, the intent argument is used (eventually) by SGX's ->mprotect() > >>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a > >>> subset of the declared/intended protections. > >>> > >>> If ->mprotect() is not merged, then it yes, it will be unused. > >> > >> OK, I think I've got it. > >> > >> I think I'm OK with adding ->mprotect(). As long as folks buy into the > >> argument that intent needs to be checked at mmap() time, they obviously > >> need to be checked at mprotect() too. > >> > >> Jarkko, if you want to try and rewrite the changelog, capturing the > >> discussion here and reply, I think I can ack the resulting patch. I > >> don't know if that will satisfy the request from Boris from an ack from > >> a "mm person", but we can at least start there. :) > > > > I think what it needs, based on what I've read, is the step by step > > description of the EMODPE scenarion without this callback and with it. > > EMODPE is virtually irrelevant for this whole thing. The x86 PTE > permissions still specify the most restrictive permissions, which is > what matters the most. > > We care about the _worst_ the enclave can do, not what it imposes on > itself on top of that. AFAIK it is not, or what we are protecting against with this anyway then? Let say an LSM makes decision for the permissions based on origin. If we do not have this you can: 1. EMODPE 2. mprotect I.e. whatever LSM decides, won't matter. The other case, noexec, is now unconditionally denied. > > I think other important thing to underline is that an LSM or any other > > security measure can only do a sane decision when the enclave is loaded. > > At that point we know the source (vm_file). > > Right, you know the source, but it can be anonymous or a file. They are both origin, the point being that you know what you're dealing with when you build the enclave, not when you map it. This is my current rewrite of the commit message in my master branch: " mm: Add 'mprotect' callback to vm_ops Intel Sofware Guard eXtensions (SGX) allows creation of blobs called enclaves, for which page permissions are defined when the enclave is first loaded. Once an enclave is loaded and initialized, it can be mapped to the process address space. There is no standard file format for enclaves. They are dynamically built and the ways how enclaves are deployed differ greatly. For an app you might want to have a simple static binary, but on the other hand for a container you might want to dynamically create the whole thing at run-time. Also, the existing ecosystem for SGX is already large, which would make the task very hard. Finally, even if there was a standard format, one would still want a dynamic way to add pages to the enclave. One big reason for this is that enclaves have load time defined pages that represent entry points to the enclave. Each entry point can service one hardware thread at a time and you might want to run-time parametrize this depending on your environment. The consequence is that enclaves are best created with an ioctl API and the access control can be based only to the origin of the source file for the enclave data, i.e. on VMA file pointer and page permissions. For example, this could be done with LSM hooks that are triggered in the appropriate ioctl's and they could make the access control decision based on this information. Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to upgrade its permissions. If we do not limit mmap() and mprotect(), enclave could upgrade its permissions by using EMODPE followed by an appropriate mprotect() call. This would be completely hidden from the kernel. Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX that will ensure that {mmap, mprotect}() permissions do not surpass any of the original page permissions. This feature allows to maintain and refine sane access control for enclaves. " I'm mostly happy with this but am open for change suggestions. /Jarkko
On 9/28/20 9:19 AM, Jarkko Sakkinen wrote: > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote: >> EMODPE is virtually irrelevant for this whole thing. The x86 PTE >> permissions still specify the most restrictive permissions, which is >> what matters the most. >> >> We care about the _worst_ the enclave can do, not what it imposes on >> itself on top of that. > > AFAIK it is not, or what we are protecting against with this anyway > then? > > Let say an LSM makes decision for the permissions based on origin. If we > do not have this you can: > > 1. EMODPE > 2. mprotect The thing that matters is that the enclave needs relaxed permissions from the kernel. What it *ALSO* needs to do to *ITSELF* to get those permissions is entirely irrelevant to the kernel. > I.e. whatever LSM decides, won't matter. > > The other case, noexec, is now unconditionally denied. >>> I think other important thing to underline is that an LSM or any other >>> security measure can only do a sane decision when the enclave is loaded. >>> At that point we know the source (vm_file). >> >> Right, you know the source, but it can be anonymous or a file. > > They are both origin, the point being that you know what you're dealing > with when you build the enclave, not when you map it. > > This is my current rewrite of the commit message in my master branch: > > " > mm: Add 'mprotect' callback to vm_ops > > Intel Sofware Guard eXtensions (SGX) allows creation of blobs called > enclaves, for which page permissions are defined when the enclave is first > loaded. Once an enclave is loaded and initialized, it can be mapped to the > process address space. > > There is no standard file format for enclaves. They are dynamically built > and the ways how enclaves are deployed differ greatly. For an app you might > want to have a simple static binary, but on the other hand for a container > you might want to dynamically create the whole thing at run-time. Also, the > existing ecosystem for SGX is already large, which would make the task very > hard. I'm sorry I ever mentioned the file format. Please remove any mention of it. It's irrelevant. This entire paragraph is irrelevant. > Finally, even if there was a standard format, one would still want a > dynamic way to add pages to the enclave. One big reason for this is that > enclaves have load time defined pages that represent entry points to the > enclave. Each entry point can service one hardware thread at a time and > you might want to run-time parametrize this depending on your environment. I also don't know what this paragraph has to do with the mprotect() hook. Please remove it. > The consequence is that enclaves are best created with an ioctl API and the > access control can be based only to the origin of the source file for the > enclave data, i.e. on VMA file pointer and page permissions. For example, It's not strictly page permissions, though. It's actually VMA permissions. The thing you copy from might be the zero page, and even though it has Write=0 page permissions, apps are completely OK to write to the address. This is the WRITE vs. MAY_WRITE semantic in the VMA flags. It's also not just about *files*. Anonymous memory might or might not be a valid source for enclave data based on LSM hooks. > this could be done with LSM hooks that are triggered in the appropriate > ioctl's and they could make the access control decision based on this > information. This "appropriate ioctl's" is not good changelog material. Please use those bytes to convey actual information. ... this could be done with LSM hooks which restrict the source of enclave page data I don't care that it's an ioctl(), really. What matters is what the ioctl() does: copy data into enclave pages. > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave > could upgrade its permissions by using EMODPE followed by an appropriate > mprotect() call. This would be completely hidden from the kernel. There's too much irrelevant info. I'll say it again: all that matters is that enclaves can legitimately, safely, and securely have a need for the kernel to change page permissions. That's *IT*. EMODPE just happens to be part of the mechanism that makes these permission changes safe for enclaves. It's a side show. > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX > that will ensure that {mmap, mprotect}() permissions do not surpass any of > the original page permissions. This feature allows to maintain and refine > sane access control for enclaves. Instead of "original", I'd stick to the "source" page nomenclature. There are also "original" permissions with mprotect(). Also, it's literally OK for the enclave page permissions to surpass the original (source) page permissions. That sentence is incorrect, or at least misleadingly imprecise. > I'm mostly happy with this but am open for change suggestions. I wrote a pretty nice description of this. It was about 90% correct, shorter, and conveyed more information. I'd suggest starting with that.
On Mon, Sep 28, 2020 at 09:48:10AM -0700, Dave Hansen wrote: > On 9/28/20 9:19 AM, Jarkko Sakkinen wrote: > > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote: > >> EMODPE is virtually irrelevant for this whole thing. The x86 PTE > >> permissions still specify the most restrictive permissions, which is > >> what matters the most. > >> > >> We care about the _worst_ the enclave can do, not what it imposes on > >> itself on top of that. > > > > AFAIK it is not, or what we are protecting against with this anyway > > then? > > > > Let say an LSM makes decision for the permissions based on origin. If we > > do not have this you can: > > > > 1. EMODPE > > 2. mprotect > > The thing that matters is that the enclave needs relaxed permissions > from the kernel. What it *ALSO* needs to do to *ITSELF* to get those > permissions is entirely irrelevant to the kernel. Lets try to find the root of misunderstanding, shall we? I'm assuming that your statement is encapsulated to: https://lore.kernel.org/linux-sgx/32fc9df4-d4aa-6768-aa06-0035427b7535@intel.com/ I do agree with this. And here is a direct quote: "It is also stashed off and then later compared with enclave PTEs to ensure that any future mmap()/mprotect() operations performed by the enclave creator or the enclave itself are consistent with the earlier declared permissions." Without the mprotect callback in place, by using EMODPE and mprotect, one could surpass the permisssions that we declared earlier. With the callback in place this is not possible. EMODPE can be freely used but mprotect() always caps the permissions. It enables us to *not care* about EMODPE. My problem is that I fully agree what you say in your description but disagree on that EMODPE should not be mentioned. > > There is no standard file format for enclaves. They are dynamically built > > and the ways how enclaves are deployed differ greatly. For an app you might > > want to have a simple static binary, but on the other hand for a container > > you might want to dynamically create the whole thing at run-time. Also, the > > existing ecosystem for SGX is already large, which would make the task very > > hard. > > I'm sorry I ever mentioned the file format. Please remove any mention > of it. It's irrelevant. This entire paragraph is irrelevant. Not sure if it is or not. It is merely to state that execve() path is possible. Perhaps should be toned down in some way. Should be like the a small remark at most. > > Finally, even if there was a standard format, one would still want a > > dynamic way to add pages to the enclave. One big reason for this is that > > enclaves have load time defined pages that represent entry points to the > > enclave. Each entry point can service one hardware thread at a time and > > you might want to run-time parametrize this depending on your environment. > > I also don't know what this paragraph has to do with the mprotect() > hook. Please remove it. Agreed. > > The consequence is that enclaves are best created with an ioctl API and the > > access control can be based only to the origin of the source file for the > > enclave data, i.e. on VMA file pointer and page permissions. For example, > > It's not strictly page permissions, though. It's actually VMA > permissions. The thing you copy from might be the zero page, and even > though it has Write=0 page permissions, apps are completely OK to write > to the address. This is the WRITE vs. MAY_WRITE semantic in the VMA flags. > > It's also not just about *files*. Anonymous memory might or might not > be a valid source for enclave data based on LSM hooks. Yes, this should be refined, agreed. Source can be either anonymous page or a file, I do of course understand that. > > this could be done with LSM hooks that are triggered in the appropriate > > ioctl's and they could make the access control decision based on this > > information. > > This "appropriate ioctl's" is not good changelog material. Please use > those bytes to convey actual information. > > ... this could be done with LSM hooks which restrict the source > of enclave page data > > I don't care that it's an ioctl(), really. What matters is what the > ioctl() does: copy data into enclave pages. Agreed. > > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to > > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave > > could upgrade its permissions by using EMODPE followed by an appropriate > > mprotect() call. This would be completely hidden from the kernel. > > There's too much irrelevant info. > > I'll say it again: all that matters is that enclaves can legitimately, > safely, and securely have a need for the kernel to change page > permissions. That's *IT*. EMODPE just happens to be part of the > mechanism that makes these permission changes safe for enclaves. It's a > side show. Disagree on this. I wrote my statement about. Maybe it should not be driving argument but should be definitely part of the description. > > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX > > that will ensure that {mmap, mprotect}() permissions do not surpass any of > > the original page permissions. This feature allows to maintain and refine > > sane access control for enclaves. > > Instead of "original", I'd stick to the "source" page nomenclature. > There are also "original" permissions with mprotect(). > > Also, it's literally OK for the enclave page permissions to surpass the > original (source) page permissions. That sentence is incorrect, or at > least misleadingly imprecise. Yes it is. It's fine to use EMODPE to upgrade the perms, and by having this hook, doing anything nasty with it is impossible. > > I'm mostly happy with this but am open for change suggestions. > > I wrote a pretty nice description of this. It was about 90% correct, > shorter, and conveyed more information. I'd suggest starting with that. I should have added a disclaimer that my description is not up to date. Just do not want to make anything final before this EMODPE discussion has some conclusion. I'm fine using your description as basis for the commit message if as long as these few details are settled. /Jarkko
On 9/28/20 12:32 PM, Jarkko Sakkinen wrote: > My problem is that I fully agree what you say in your description but > disagree on that EMODPE should not be mentioned. I'll just be very clear: I'm not willing to ack any patch with a changelog that has more than a passing mention of EMODPE. Do what you think is best, but if sticking to your guns may deplete the pool of folks willing to ack your patch.
On Mon, Sep 28, 2020 at 09:48:10AM -0700, Dave Hansen wrote: > On 9/28/20 9:19 AM, Jarkko Sakkinen wrote: > > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote: > >> EMODPE is virtually irrelevant for this whole thing. The x86 PTE > >> permissions still specify the most restrictive permissions, which is > >> what matters the most. > >> > >> We care about the _worst_ the enclave can do, not what it imposes on > >> itself on top of that. > > > > AFAIK it is not, or what we are protecting against with this anyway > > then? > > > > Let say an LSM makes decision for the permissions based on origin. If we > > do not have this you can: > > > > 1. EMODPE > > 2. mprotect > > The thing that matters is that the enclave needs relaxed permissions > from the kernel. What it *ALSO* needs to do to *ITSELF* to get those > permissions is entirely irrelevant to the kernel. Lets try to find the root of misunderstanding, shall we? I'm assuming that your statement is encapsulated to: https://lore.kernel.org/linux-sgx/32fc9df4-d4aa-6768-aa06-0035427b7535@intel.com/ I do agree with this. And here is a direct quote: "It is also stashed off and then later compared with enclave PTEs to ensure that any future mmap()/mprotect() operations performed by the enclave creator or the enclave itself are consistent with the earlier declared permissions." Without the mprotect callback in place, by using EMODPE and mprotect, one could surpass the permisssions that we declared earlier. With the callback in place this is not possible. EMODPE can be freely used but mprotect() always caps the permissions. It enables us to *not care* about EMODPE. My problem is that I fully agree what you say in your description but disagree on that EMODPE should not be mentioned. > > There is no standard file format for enclaves. They are dynamically built > > and the ways how enclaves are deployed differ greatly. For an app you might > > want to have a simple static binary, but on the other hand for a container > > you might want to dynamically create the whole thing at run-time. Also, the > > existing ecosystem for SGX is already large, which would make the task very > > hard. > > I'm sorry I ever mentioned the file format. Please remove any mention > of it. It's irrelevant. This entire paragraph is irrelevant. Not sure if it is or not. It is merely to state that execve() path is possible. Perhaps should be toned down in some way. Should be like the a small remark at most. > > Finally, even if there was a standard format, one would still want a > > dynamic way to add pages to the enclave. One big reason for this is that > > enclaves have load time defined pages that represent entry points to the > > enclave. Each entry point can service one hardware thread at a time and > > you might want to run-time parametrize this depending on your environment. > > I also don't know what this paragraph has to do with the mprotect() > hook. Please remove it. Agreed. > > The consequence is that enclaves are best created with an ioctl API and the > > access control can be based only to the origin of the source file for the > > enclave data, i.e. on VMA file pointer and page permissions. For example, > > It's not strictly page permissions, though. It's actually VMA > permissions. The thing you copy from might be the zero page, and even > though it has Write=0 page permissions, apps are completely OK to write > to the address. This is the WRITE vs. MAY_WRITE semantic in the VMA flags. > > It's also not just about *files*. Anonymous memory might or might not > be a valid source for enclave data based on LSM hooks. Yes, this should be refined, agreed. Source can be either anonymous page or a file, I do of course understand that. > > this could be done with LSM hooks that are triggered in the appropriate > > ioctl's and they could make the access control decision based on this > > information. > > This "appropriate ioctl's" is not good changelog material. Please use > those bytes to convey actual information. > > ... this could be done with LSM hooks which restrict the source > of enclave page data > > I don't care that it's an ioctl(), really. What matters is what the > ioctl() does: copy data into enclave pages. Agreed. > > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to > > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave > > could upgrade its permissions by using EMODPE followed by an appropriate > > mprotect() call. This would be completely hidden from the kernel. > > There's too much irrelevant info. > > I'll say it again: all that matters is that enclaves can legitimately, > safely, and securely have a need for the kernel to change page > permissions. That's *IT*. EMODPE just happens to be part of the > mechanism that makes these permission changes safe for enclaves. It's a > side show. Disagree on this. I wrote my statement about. Maybe it should not be driving argument but should be definitely part of the description. > > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX > > that will ensure that {mmap, mprotect}() permissions do not surpass any of > > the original page permissions. This feature allows to maintain and refine > > sane access control for enclaves. > > Instead of "original", I'd stick to the "source" page nomenclature. > There are also "original" permissions with mprotect(). > > Also, it's literally OK for the enclave page permissions to surpass the > original (source) page permissions. That sentence is incorrect, or at > least misleadingly imprecise. Yes it is. It's fine to use EMODPE to upgrade the perms, and by having this hook, doing anything nasty with it is impossible. > > I'm mostly happy with this but am open for change suggestions. > > I wrote a pretty nice description of this. It was about 90% correct, > shorter, and conveyed more information. I'd suggest starting with that. I should have added a disclaimer that my description is not up to date. Just do not want to make anything final before this EMODPE discussion has some conclusion. I'm fine using your description as basis for the commit message if as long as these few details are settled. /Jarkko
On Mon, Sep 28, 2020 at 12:45:27PM -0700, Dave Hansen wrote: > On 9/28/20 12:32 PM, Jarkko Sakkinen wrote: > > My problem is that I fully agree what you say in your description but > > disagree on that EMODPE should not be mentioned. > > I'll just be very clear: I'm not willing to ack any patch with a > changelog that has more than a passing mention of EMODPE. > > Do what you think is best, but if sticking to your guns may deplete the > pool of folks willing to ack your patch. I do see it mentioned in other responses too in this thread, and not just mine. And here is even a request to get it to the changelog: https://lore.kernel.org/linux-sgx/1B23E216-0229-4BDD-8B09-807256A54AF5@amacapital.net/ I'm absolutely fine not to mention EMODPE but after re-reading the thread, it is not like there is one voice on it. I don't really care all that much whether it is mentioned or not but there should be some reasonable logic behind the decision. PS. I just noticed that my previous response did not reach lore so I bounced it again. /Jarkko
> On Sep 28, 2020, at 1:20 PM, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote: > > On Mon, Sep 28, 2020 at 12:45:27PM -0700, Dave Hansen wrote: >>> On 9/28/20 12:32 PM, Jarkko Sakkinen wrote: >>> My problem is that I fully agree what you say in your description but >>> disagree on that EMODPE should not be mentioned. >> >> I'll just be very clear: I'm not willing to ack any patch with a >> changelog that has more than a passing mention of EMODPE. >> >> Do what you think is best, but if sticking to your guns may deplete the >> pool of folks willing to ack your patch. > > I do see it mentioned in other responses too in this thread, and not > just mine. > > And here is even a request to get it to the changelog: > > https://lore.kernel.org/linux-sgx/1B23E216-0229-4BDD-8B09-807256A54AF5@amacapital.net/ > > I'm absolutely fine not to mention EMODPE but after re-reading the > thread, it is not like there is one voice on it. I don't really > care all that much whether it is mentioned or not but there should > be some reasonable logic behind the decision. I don’t personally care that much about EMODPE but, you could probably get the point across with something like: SGX’s EPCM permission bits do not obviate the need to enforce these rules in the PTEs because enclaves can freely modify the EPCM permissions using EMODPE. IOW, EMODPE is not really special here; rather, EMODPE’s existence demonstrates that EADD / EEXTEND are not special.
On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote: > I don’t personally care that much about EMODPE but, you could probably > get the point across with something like: > > SGX’s EPCM permission bits do not obviate the need to enforce these > rules in the PTEs because enclaves can freely modify the EPCM > permissions using EMODPE. > > IOW, EMODPE is not really special here; rather, EMODPE’s existence > demonstrates that EADD / EEXTEND are not special. So I did "disagree and commit" with this one. I'm not actually diagreeing on anything what Dave wrote, on the contrary it is an understandable high level description. I just thought that it would not hurt to remark that the ISA contains such peculiarities as EMODPE. I did only very rudimentary clean up for the text (e.g. fix the ioctl name, add shortt summary and not much else). Does not make sense to waste more time to this. I'll move on to implement the missing boot time patching for the vDSO so that we get the next version out. " mm: Add 'mprotect' hook to struct vm_operations_struct Background ========== 1. SGX enclave pages are populated with data by copying data to them from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). 2. We want to be able to restrict those normal memory data sources. For instance, before copying data to an executable enclave page, we might ensure that the source is executable. 3. Enclave page permissions are dynamic just like normal permissions and can be adjusted at runtime with mprotect() (along with a corresponding special instruction inside the enclave). 4. The original data source may have have long since vanished at the time when enclave page permission are established (mmap() or mprotect()). Solution ======== The solution is to force enclaves creators to declare their intent up front to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). This intent can me immediately compared to the source data mapping (and rejected if necessary). It is also stashed off and then later compared with enclave PTEs to ensure that any future mmap()/mprotect() operations performed by the enclave creator or the enclave itself are consistent with the earlier declared permissions. Essentially, this means that whenever the kernel is asked to change an enclave PTE, it needs to ensure the change is consistent with that stashed intent. There is an existing vm_ops->mmap() hook which allows SGX to do that for mmap(). However, there is no ->mprotect() hook. Add a vm_ops->mprotect() hook so that mprotect() operations which are inconsistent with any page's stashed intent can be rejected by the driver. Implications ============ However, there is currently no implementation of the intent checks at the time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). That means that the intent argument (SGX_PROT_*) is currently unused. " /Jarkko
On 9/28/20 9:05 PM, Jarkko Sakkinen wrote: > On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote: >> I don’t personally care that much about EMODPE but, you could probably >> get the point across with something like: >> >> SGX’s EPCM permission bits do not obviate the need to enforce these >> rules in the PTEs because enclaves can freely modify the EPCM >> permissions using EMODPE. >> >> IOW, EMODPE is not really special here; rather, EMODPE’s existence >> demonstrates that EADD / EEXTEND are not special. > > So I did "disagree and commit" with this one. I'm not actually > diagreeing on anything what Dave wrote, on the contrary it is an > understandable high level description. I just thought that it would not > hurt to remark that the ISA contains such peculiarities as EMODPE. > > I did only very rudimentary clean up for the text (e.g. fix the ioctl > name, add shortt summary and not much else). > > Does not make sense to waste more time to this. I'll move on to > implement the missing boot time patching for the vDSO so that we > get the next version out. > > " > mm: Add 'mprotect' hook to struct vm_operations_struct > > Background > ========== > > 1. SGX enclave pages are populated with data by copying data to them > from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). > 2. We want to be able to restrict those normal memory data sources. For > instance, before copying data to an executable enclave page, we might > ensure that the source is executable. I know I wrote that. I suck, and I wrote it in a changelog-unacceptable way. Folks dislike the use of "we" in these things. Here's a better version: 2. It is desirable to be able to restrict those normal memory data sources. For instance, the kernel can ensure that the source is executable, before copying data to an executable enclave page. > 3. Enclave page permissions are dynamic just like normal permissions and > can be adjusted at runtime with mprotect() (along with a > corresponding special instruction inside the enclave). > 4. The original data source may have have long since vanished at the > time when enclave page permission are established (mmap() or > mprotect()). > > Solution > ======== > > The solution is to force enclaves creators to declare their intent up front > to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). This intent can me immediately > compared to the source data mapping (and rejected if necessary). It is > also stashed off and then later compared with enclave PTEs to ensure that > any future mmap()/mprotect() operations performed by the enclave creator or > the enclave itself are consistent with the earlier declared permissions. Let's also say "... or *requested* by the enclave itself ...", since the enclave itself can't directly make syscalls. > Essentially, this means that whenever the kernel is asked to change an > enclave PTE, it needs to ensure the change is consistent with that stashed > intent. There is an existing vm_ops->mmap() hook which allows SGX to do > that for mmap(). However, there is no ->mprotect() hook. Add a > vm_ops->mprotect() hook so that mprotect() operations which are > inconsistent with any page's stashed intent can be rejected by the driver. > > Implications > ============ > > However, there is currently no implementation of the intent checks at the > time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). That means that the intent > argument (SGX_PROT_*) is currently unused. This was incorrect to say. Sean corrected me on this point. Could you look through the thread and incorporate that?
On Tue, Sep 29, 2020 at 07:24:24AM -0700, Dave Hansen wrote: > On 9/28/20 9:05 PM, Jarkko Sakkinen wrote: > > On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote: > >> I don’t personally care that much about EMODPE but, you could probably > >> get the point across with something like: > >> > >> SGX’s EPCM permission bits do not obviate the need to enforce these > >> rules in the PTEs because enclaves can freely modify the EPCM > >> permissions using EMODPE. > >> > >> IOW, EMODPE is not really special here; rather, EMODPE’s existence > >> demonstrates that EADD / EEXTEND are not special. > > > > So I did "disagree and commit" with this one. I'm not actually > > diagreeing on anything what Dave wrote, on the contrary it is an > > understandable high level description. I just thought that it would not > > hurt to remark that the ISA contains such peculiarities as EMODPE. > > > > I did only very rudimentary clean up for the text (e.g. fix the ioctl > > name, add shortt summary and not much else). > > > > Does not make sense to waste more time to this. I'll move on to > > implement the missing boot time patching for the vDSO so that we > > get the next version out. > > > > " > > mm: Add 'mprotect' hook to struct vm_operations_struct > > > > Background > > ========== > > > > 1. SGX enclave pages are populated with data by copying data to them > > from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). > > 2. We want to be able to restrict those normal memory data sources. For > > instance, before copying data to an executable enclave page, we might > > ensure that the source is executable. > > I know I wrote that. I suck, and I wrote it in a changelog-unacceptable > way. Folks dislike the use of "we" in these things. Here's a better > version: > > 2. It is desirable to be able to restrict those normal memory data > sources. For instance, the kernel can ensure that the source is > executable, before copying data to an executable enclave page. > > > 3. Enclave page permissions are dynamic just like normal permissions and > > can be adjusted at runtime with mprotect() (along with a > > corresponding special instruction inside the enclave). > > 4. The original data source may have have long since vanished at the > > time when enclave page permission are established (mmap() or > > mprotect()). > > > > Solution > > ======== > > > > The solution is to force enclaves creators to declare their intent up front > > to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). This intent can me immediately > > compared to the source data mapping (and rejected if necessary). It is > > also stashed off and then later compared with enclave PTEs to ensure that > > any future mmap()/mprotect() operations performed by the enclave creator or > > the enclave itself are consistent with the earlier declared permissions. > > Let's also say "... or *requested* by the enclave itself ...", since the > enclave itself can't directly make syscalls. Yes, it is definitely more understandable way to say it. Do you mind if I rephrase it as: "It is also stashed off and then later compared with enclave PTEs to ensure that any future mmap()/mprotect() operations performed by the enclave creator or requested the enclave by itself (e.g. by issuing ECLU[EMODPE]) are consistent with the earlier declared permissions." I'd just mention EMODPE as an example, but I'm also perfectly fine leaving that out :-) Not a big deal for me. Also, should there be commas, i.e. ", or requested the enclave by itself,"? I suck with English comma rules. > > Essentially, this means that whenever the kernel is asked to change an > > enclave PTE, it needs to ensure the change is consistent with that stashed > > intent. There is an existing vm_ops->mmap() hook which allows SGX to do > > that for mmap(). However, there is no ->mprotect() hook. Add a > > vm_ops->mprotect() hook so that mprotect() operations which are > > inconsistent with any page's stashed intent can be rejected by the driver. > > > > Implications > > ============ > > > > However, there is currently no implementation of the intent checks at the > > time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). That means that the intent > > argument (SGX_PROT_*) is currently unused. > > This was incorrect to say. Sean corrected me on this point. Could you > look through the thread and incorporate that? OK, so we are probably talking about [1] here, right? There are at least two checks done with and without the callback: A. TCS pages are required to be passed with zero EPCM permissions, the reason being that CPU will silently overwrite its permissions zero. This check resides in sgx_validate_secinfo() [2]. B. noexec partitions are unconditionally disallowed. This check resides in __sgx_encl_add_page() [2]. TCS pages are funky in the way that they are also required to be mapped as RW. OK, then you might argue that why not just require RW as ioctl supplied permissions. That would cause a mismatch with CPU calculated MRENCLAVE and one calculated to SIGSTRUCT. I've written in past quite length explanation of this to the kdoc of sgx_ioc_enclave_add_pages() [2]. This was something that I did not find from Sean's response. To encompensate all this information in a paragraph, I'd write along the lines of "ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES, ...) checks for every page that Thread Control Structure (TCS) pages are always added with zero permissions and no pages are sourced from noexec partitions. TCS pages are pages that work as entry points to the enclave. This is the basic acceptance criteria for any enclave page before it gets mapped. After finishing this, the ioctl will project the enclave permissions to the corresponding VMA permissions and stores the result for later lookup. For regular pages this is an identity mapping but as an exception TCS pages are unconditionally mapped as RW VMA permssion even though their enclave permissions are zero. This required by the ISA. This information will be used by sgx_mmap() and sgx_vma_protect() to enforce that higher permissions than the projected permissions will not be used by checking this for each every page in the address range. By doing this, we give assets for LSM's to make decisions during the build time based on projected VMA permissions and the source VMA (either a file or anonymous mapping) that hold when the enclave is finally mapped to the visible memory." Is this sufficient? [1] https://lore.kernel.org/linux-sgx/20200915112842.897265-1-jarkko.sakkinen@linux.intel.com/T/#m7e84af96d63dd8ec528422cfc942f42e3bdf4356 [2] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/kernel/cpu/sgx/ioctl.c /Jarkko
On 9/29/20 5:20 PM, Jarkko Sakkinen wrote: > On Tue, Sep 29, 2020 at 07:24:24AM -0700, Dave Hansen wrote: >> On 9/28/20 9:05 PM, Jarkko Sakkinen wrote: >>> On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote: >>>> I don’t personally care that much about EMODPE but, you could probably >>>> get the point across with something like: >>>> >>>> SGX’s EPCM permission bits do not obviate the need to enforce these >>>> rules in the PTEs because enclaves can freely modify the EPCM >>>> permissions using EMODPE. >>>> >>>> IOW, EMODPE is not really special here; rather, EMODPE’s existence >>>> demonstrates that EADD / EEXTEND are not special. >>> >>> So I did "disagree and commit" with this one. I'm not actually >>> diagreeing on anything what Dave wrote, on the contrary it is an >>> understandable high level description. I just thought that it would not >>> hurt to remark that the ISA contains such peculiarities as EMODPE. >>> >>> I did only very rudimentary clean up for the text (e.g. fix the ioctl >>> name, add shortt summary and not much else). >>> >>> Does not make sense to waste more time to this. I'll move on to >>> implement the missing boot time patching for the vDSO so that we >>> get the next version out. >>> >>> " >>> mm: Add 'mprotect' hook to struct vm_operations_struct >>> >>> Background >>> ========== >>> >>> 1. SGX enclave pages are populated with data by copying data to them >>> from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). >>> 2. We want to be able to restrict those normal memory data sources. For >>> instance, before copying data to an executable enclave page, we might >>> ensure that the source is executable. >> >> I know I wrote that. I suck, and I wrote it in a changelog-unacceptable >> way. Folks dislike the use of "we" in these things. Here's a better >> version: >> >> 2. It is desirable to be able to restrict those normal memory data >> sources. For instance, the kernel can ensure that the source is >> executable, before copying data to an executable enclave page. >> >>> 3. Enclave page permissions are dynamic just like normal permissions and >>> can be adjusted at runtime with mprotect() (along with a >>> corresponding special instruction inside the enclave). >>> 4. The original data source may have have long since vanished at the >>> time when enclave page permission are established (mmap() or >>> mprotect()). >>> >>> Solution >>> ======== >>> >>> The solution is to force enclaves creators to declare their intent up front >>> to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). This intent can me immediately >>> compared to the source data mapping (and rejected if necessary). It is >>> also stashed off and then later compared with enclave PTEs to ensure that >>> any future mmap()/mprotect() operations performed by the enclave creator or >>> the enclave itself are consistent with the earlier declared permissions. >> >> Let's also say "... or *requested* by the enclave itself ...", since the >> enclave itself can't directly make syscalls. > > Yes, it is definitely more understandable way to say it. Do you mind > if I rephrase it as: > > "It is also stashed off and then later compared with enclave PTEs to > ensure that any future mmap()/mprotect() operations performed by the > enclave creator or requested the enclave by itself (e.g. by issuing > ECLU[EMODPE]) are consistent with the earlier declared permissions." > > I'd just mention EMODPE as an example, but I'm also perfectly fine > leaving that out :-) Not a big deal for me. If I say it's a big deal for me, will you remove the bloody thing? Mentioning EMODPE is a distraction for this patch. It's a big distraction because it makes it sound like it is some kind of *peer* of mmap()/mprotect(). It's not. It's subservient to x86 paging protections and thus *IRRELEVANT* for this unless you care about the intricacies of writing enclaves. It's a big deal to me. Also, I've tried to give this feedback previously, but the paging permissions are also essentially irrelevant. > Also, should there be commas, i.e. ", or requested the enclave by > itself,"? I suck with English comma rules. I'd just say this: It is also stashed off and then later compared with enclave PTEs to ensure that any future mmap()/mprotect() operations are consistent with the earlier declared permissions. Yours was starting to look pretty run on. > "ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES, ...) checks for every page that > Thread Control Structure (TCS) pages are always added with zero > permissions and no pages are sourced from noexec partitions. TCS pages > are pages that work as entry points to the enclave. This is the basic > acceptance criteria for any enclave page before it gets mapped. This is going off into the SGX weeds again. We don't need to justify the ABI for an ioctl() introduced in a different patch in *THIS* patch. Just remove this, please. > After finishing this, the ioctl will project the enclave permissions to > the corresponding VMA permissions and stores the result for later > lookup. That sounds vaguely relevant, although I'm not sure what permission projection is. You use that terminology over and over, so you probably need to define it. > For regular pages this is an identity mapping but as an > exception TCS pages are unconditionally mapped as RW VMA permssion even > though their enclave permissions are zero. This required by the ISA. I don't think this is relevant. > This information will be used by sgx_mmap() and sgx_vma_protect() to > enforce that higher permissions than the projected permissions will > not be used by checking this for each every page in the address > range. I've given this feedback before. Please don't use "higher" and "lower" permissions. "Stronger/weaker" is my preferred terminology. You also don't have to *NAME* the functions. If I want to know where a structure field is, grep is a better way to find that. Does this lose any meaning if we just say: This information will be to ensure that enclave PTEs will not be created with permissions weaker than the source data ? > By doing this, we give assets for LSM's to make decisions during the > build time based on projected VMA permissions and the source VMA > (either a file or anonymous mapping) that hold when the enclave is > finally mapped to the visible memory."
On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote: Good morning, I hope the weekend is going well for everyone. > On 9/27/20 5:53 PM, Jarkko Sakkinen wrote: > > On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote: > >> On 9/25/20 12:43 PM, Sean Christopherson wrote: > >>>> That means that the intent argument (SGX_PROT_*) is currently unused. > >>> No, the intent argument is used (eventually) by SGX's ->mprotect() > >>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a > >>> subset of the declared/intended protections. > >>> > >>> If ->mprotect() is not merged, then it yes, it will be unused. > >> > >> OK, I think I've got it. > >> > >> I think I'm OK with adding ->mprotect(). As long as folks buy into the > >> argument that intent needs to be checked at mmap() time, they obviously > >> need to be checked at mprotect() too. > >> > >> Jarkko, if you want to try and rewrite the changelog, capturing the > >> discussion here and reply, I think I can ack the resulting patch. I > >> don't know if that will satisfy the request from Boris from an ack from > >> a "mm person", but we can at least start there. :) > > > > I think what it needs, based on what I've read, is the step by step > > description of the EMODPE scenarion without this callback and with it. > > EMODPE is virtually irrelevant for this whole thing. The x86 PTE > permissions still specify the most restrictive permissions, which is > what matters the most. > > We care about the _worst_ the enclave can do, not what it imposes on > itself on top of that. > > > I think other important thing to underline is that an LSM or any other > > security measure can only do a sane decision when the enclave is loaded. > > At that point we know the source (vm_file). > > Right, you know the source, but it can be anonymous or a file. Or it could be loaded over the network in encrypted form by the enclave itself. Sean, admirably, wants to peer into the future and set the driver up from an architectural perspective, to future proof it for the imposition of security controls. So it would seem helpful to peer a bit. If I can paraphrase/simplify the discussion to date; the best the kernel can do with respect to SGX is to impose controls, via mprotect, that limit the maximum permissions of an enclave page to whatever was specified when the enclave was loaded/initialized. So here is the question that would seem to need answering: Is this even a relevant control if we cede the notion of dynamically loadable enclave code, which is the objective of SGX2 hardware, which will in all likelihood be the only relevant hardware implementation in the future? The answer to this could very well be yes if the objective is to provide a method for a platform owner to explicitly block dynamically loadable enclave code. Since there seems to be a desire for immense clarity in the changelogs surrounding all of this, framing the discussion in something practical like this may be of assistance. One of the desires of the SGX user community is to not allow visibility into enclave code, this is one of the notions/objectives of confidential computing. The Protected Code Loader that was added by Intel to their PSW is an acknowledgement of this fact. EDMM and dynamically loadable code makes doing this much more efficient so that would seem to be the face of the future. My apologies for 'delaying' the driver even more. I was accused of that about a year ago but it appears I didn't do too much damage... :-) Best wishes for a productive week. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "If you get to thinkin' you're a person of some influence, try orderin' somebody else's dog around." -- Cowboy Wisdom
On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote: > Is this even a relevant control if we cede the notion of dynamically > loadable enclave code, which is the objective of SGX2 hardware, which > will in all likelihood be the only relevant hardware implementation in > the future? Yes, it's still relevant. Giving the thumbs up to dynamically loadable code is not a purely binary decision, e.g. a user/admin can allow RW->RX transitions but still disallow full RWX permissions.
On Mon, Oct 19, 2020 at 02:31:05PM -0700, Sean Christopherson wrote: Good morning, I hope the day is starting well for everyone. > On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote: > > Is this even a relevant control if we cede the notion of dynamically > > loadable enclave code, which is the objective of SGX2 hardware, which > > will in all likelihood be the only relevant hardware implementation in > > the future? > Yes, it's still relevant. Giving the thumbs up to dynamically > loadable code is not a purely binary decision, e.g. a user/admin can > allow RW->RX transitions but still disallow full RWX permissions. With respect to the security issue at hand, the only relevant issue would seem to be if a page had write permissions at one time in its trajectory to having execute permisions, isn't this correct? The next paragraph of my reply wasn't included in your reply, but I did state that the mprotect hook would be relevant if its purpose was to disallow this permission trajectory and in the process disable enclave dynamic code loading and execution. So to assist everyone in understanding this issue and the security implications involved, is the ultimate purpose of the mprotect hook to disable dynamic code loading? Have a good day. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: dg@enjellic.com ------------------------------------------------------------------------------ "Those who will not study history are doomed to debug it." -- Barry Shein
On Tue, Oct 20, 2020 at 05:01:18AM -0500, Dr. Greg wrote: > On Mon, Oct 19, 2020 at 02:31:05PM -0700, Sean Christopherson wrote: > > Good morning, I hope the day is starting well for everyone. > > > On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote: > > > Is this even a relevant control if we cede the notion of dynamically > > > loadable enclave code, which is the objective of SGX2 hardware, which > > > will in all likelihood be the only relevant hardware implementation in > > > the future? > > > Yes, it's still relevant. Giving the thumbs up to dynamically > > loadable code is not a purely binary decision, e.g. a user/admin can > > allow RW->RX transitions but still disallow full RWX permissions. > > With respect to the security issue at hand, the only relevant issue > would seem to be if a page had write permissions at one time in its > trajectory to having execute permisions, isn't this correct? No. RW->RX has different properties than RWX. E.g. an enclave that dynamically loads code is not the same thing as an enclave that allows simultaneously writing and executing a page. > The next paragraph of my reply wasn't included in your reply, but I > did state that the mprotect hook would be relevant if its purpose was > to disallow this permission trajectory and in the process disable > enclave dynamic code loading and execution. > > So to assist everyone in understanding this issue and the security > implications involved, is the ultimate purpose of the mprotect hook to > disable dynamic code loading? No, it's to provide line of sight to enforcing granular LSM checks on enclave pages. Jumping back to the RWX thing, as a defense in depth measure, a policy owner could set an SELinux policy to never allow RWX, even for enclaves that dynamically load code. Whether or not having per-page granluarity on enclave permission checks is valuable/interesting is debatable, e.g. it's why LSM integration is notably absent from the this series. But, adding the ->mprotect() hook is relatively cheap and can always be removed if it's deemed unnecessary in the long run. The reverse is not true; omitting ->mprotect() commits the kernel to an ABI that is either ugly and potentially painful (require all enclaves to declare full RWX permissions), or flat out prevents adding granular LSM support in the future (do nothing).
On Tue, Oct 20, 2020 at 09:40:00AM -0700, Sean Christopherson wrote: Good morning, I hope the week has gone well for everyone. > On Tue, Oct 20, 2020 at 05:01:18AM -0500, Dr. Greg wrote: > > > > With respect to the security issue at hand, the only relevant issue > > would seem to be if a page had write permissions at one time in its > > trajectory to having execute permisions, isn't this correct? > No. RW->RX has different properties than RWX. E.g. an enclave that > dynamically loads code is not the same thing as an enclave that > allows simultaneously writing and executing a page. Yes, it is certainly correct that a platform administrator may want to restrict RWX, given that it makes an enclave susceptible to potential arbitrary code execution if there is a programming error in the enclave. However, I think it is important for everyone interested in these issues, to reflect back on what started all of this and that was Andy's concern that the initial incantations of the driver allowed execution of arbitrary memory without the ability of the LSM to get a 'look' at the code/memory. My point in all of this is that a permissions trajectory for an enclave that allows for write permissions on a path that terminates in X permissions opens the door for arbitrary memory execution that the platform security architect has no insight into or that the LSM will have any control over. There is no guarantee that dynamically loaded code has to come into the enclave via anything that the operating system has visibility into. If the enclave can toggle RW->RX it is free to dynamically load code, in encrypted form over the network and then execute it. In fact, I would posit that this model will be a primary use for dynamic code loading. The SGX user community views 'confidential computing' as much about protecting visibility into algorithms and code as it is about data that is being operated on. In certain unnamed venues where I have consulted it is the primary concern. So in the broadest sense, we have spent a year worrying about if and how the LSM will have visibility into enclave based code and in the end the only really relevant security mechanism available is limiting page permission transitions that prevent dynamic code loading. Modulo of course the issue with RWX, where a platform owner may elect to try and prevent an enclave writer from shooting themselves in the foot. The issue at hand is that the primary security threat of the technology is the same as what the user community wants to use it for. Joanna Rutkowska called that out a half decade ago when she first reviewed the technology. > > The next paragraph of my reply wasn't included in your reply, but I > > did state that the mprotect hook would be relevant if its purpose was > > to disallow this permission trajectory and in the process disable > > enclave dynamic code loading and execution. > > > > So to assist everyone in understanding this issue and the security > > implications involved, is the ultimate purpose of the mprotect hook to > > disable dynamic code loading? > No, it's to provide line of sight to enforcing granular LSM checks > on enclave pages. Jumping back to the RWX thing, as a defense in > depth measure, a policy owner could set an SELinux policy to never > allow RWX, even for enclaves that dynamically load code. > > Whether or not having per-page granluarity on enclave permission > checks is valuable/interesting is debatable, e.g. it's why LSM > integration is notably absent from the this series. But, adding the > ->mprotect() hook is relatively cheap and can always be removed if > it's deemed unnecessary in the long run. The reverse is not true; > omitting ->mprotect() commits the kernel to an ABI that is either > ugly and potentially painful (require all enclaves to declare full > RWX permissions), or flat out prevents adding granular LSM support > in the future (do nothing). I believe your analysis with respect to the ability to remove ->mprotect is flawed. The long standing consensus has been that functionality never gets broken. Once ->mprotect is a component of the ABI it would have to be left intact since it could potentially break things that elected to use it. On the other hand there is a long standing history of adding functionality. I can't bring myself to believe that LSM's are going to be written that will be making enclave security decisions on a page by page basis. Given what I have written above, I think all of this comes down to giving platform administrators one of three decisions, in order of most to least secure: 1.) Block dynamic code loading and execution. 2.) Block access to RWX pages. 3.) The wild west - no restrictions on enclave page protection manipulation. From a security perspective I would argue for the wisdom of making option 1 unconditional via a kernel command-line parameter. It may be that ->mprotect is the right mechanism to implement this. If that is the case, frame the discussion and documentation so that it reflects the actual security threat and the consideration and means for dealing with it. Hopefully all of this is useful to the stakeholders in this technology. Have a good weekend. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 19th Ave. N. Fargo, ND 58102 PH: 701-281-1686 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "Politics is the business of getting power and privilege without possessing merit." -- P.J. O'Rourke
> On Oct 24, 2020, at 7:38 AM, Dr. Greg <greg@enjellic.com> wrote: > > > I can't bring myself to believe that LSM's are going to be written > that will be making enclave security decisions on a page by page > basis. Given what I have written above, I think all of this comes > down to giving platform administrators one of three decisions, in > order of most to least secure: > > 1.) Block dynamic code loading and execution. > I don’t understand what you’re trying to say. Unless we’re going to split enclaves into multiple VMAs with different permissions, how do you expect to block dynamic code loading unless you have separate RW and RX pages? That would be “page-by-page”, right? > 2.) Block access to RWX pages. > > 3.) The wild west - no restrictions on enclave page protection manipulation. > > From a security perspective I would argue for the wisdom of making > option 1 unconditional via a kernel command-line parameter. > > It may be that ->mprotect is the right mechanism to implement this. > If that is the case, frame the discussion and documentation so that it > reflects the actual security threat and the consideration and means > for dealing with it. > > Hopefully all of this is useful to the stakeholders in this > technology. > > Have a good weekend. > > Dr. Greg > > As always, > Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive > Enjellic Systems Development, LLC IOT platforms and edge devices. > 4206 19th Ave. N. > Fargo, ND 58102 > PH: 701-281-1686 EMAIL: greg@enjellic.com > ------------------------------------------------------------------------------ > "Politics is the business of getting power and privilege without possessing > merit." > -- P.J. O'Rourke
On Sat, Oct 24, 2020 at 08:33:21AM -0700, Andy Lutomirski wrote: Good morning, I hope the week is starting well for everyone. > > On Oct 24, 2020, at 7:38 AM, Dr. Greg <greg@enjellic.com> wrote: > > I can't bring myself to believe that LSM's are going to be written > > that will be making enclave security decisions on a page by page > > basis. Given what I have written above, I think all of this comes > > down to giving platform administrators one of three decisions, in > > order of most to least secure: > > > > 1.) Block dynamic code loading and execution. > I don't understand what you're trying to say. Unless we're going to > split enclaves into multiple VMAs with different permissions, how do > you expect to block dynamic code loading unless you have separate RW > and RX pages? That would be ???page-by-page???, right? I believe that there are multiple knobs that can be manipulated to achieve the effects that are desired. I am advocating that we have a clear and reasoned understanding, with appropriate documentation, as to what we are doing and why we are doing it. To advance this understanding, I would advocate that anyone interested in these issues review the papers that describe the design and use of the SGX2 architecture instructions. Fore convenience we have them available on our FTP server via the following links: ftp://ftp.enjellic.com/pub/sgx/docs/hasp4.pdf ftp://ftp.enjellic.com/pub/sgx/docs/hasp5.pdf They are both from HASP 2016 and are readily available elsewhere as well. The first paper discusses the SGX2 architecture instructions and why they were implemented. The second paper discusses how Enclave Dynamic Memory Management (EDMM) can be implemented from the OS perspective using these instructions. Full disclosure, I've had the opportunity to have direct exchanges with a number of the authors on those papers. The design of all this was heavily influenced by Marcus Peinado's group at Microsoft. They did the first implementation of an SGX library OS (Haven) and in the process addressed the issue of dynamic memory and code loading. Their work also resulted in the documentation of a number of errata in the SGX silicon implementation. Like the company or not, I don't think the case can be made that they don't understand operating system design and theory. It would thus seem prudent to understand the prior art that went into the design of all this. To summarize at a high level, EDMM requires a rather intricate choreography between enclave code and the device driver, the latter of which needs to execute ring-0 privileged instructions in order to expand the virtual address space of an enclave. The easiest way to generically block dynamic code loading is to not allow the ENCLS[EAUG] instruction to be executed, the purpose of which is to augment a defined but sparse ELRANGE with additional physical pages from the EPC. It doesn't require ->mprotect or anything else, just a physical decision by the OS to not allow execution of that instruction. All of which is consistent with my recomendation for a global disable knob on the kernel command-line for sites that do not want to tolerate completely anonymous code execution. Since this driver does not yet support EDMM, the most immediate situation that we are dealing with are the potential security implications of SGX2 ENCLU instructions being executed inside of an enclave. The most principal issue is the ENCLU[EMODPE] instruction that allows a running enclave to extend the current permissions of a page. I've been assuming that Sean's desire for ->mprotect is to block the ability of an initialized enclave, on a non-EDMM enabled driver, to collaborate with its untrusted component to self-modify its page permissions and thus allow execution of code that the operating system has no visibility into. That would make far more sense then the notion of someone trying to create an LSM that makes page by page security decisions. The open question in all of this is that the EDMM paper, as well as the SDM, indicate the effects of an ENCLU[EMODPE] are immediate inside of a running enclave. I'm assuming that this does NOT mean that once a context of execution is running in enclave mode it would be capable of evading standard page protections but the 'immediate' is somewhat disquieting and probably deserves clarification, despite Dave Hansen's adament concerns about discussing the instruction... :-) At the risk of being widely unpopular, it may be worth calling the question if we shouldn't bite the bullet and implement full SGX2 support in the driver. Given the trajectory that SGX is on it is what everyone wants and will be using. We are currently in somewhat of a bad place since we have to be cognizant of the implications of SGX2 hardware, which is going to be the only relevant platform for this driver, without actually addressing all of the issues it brings to the table. Hopefully all of the above helps advance an understanding of the issues at hand. Have a good day. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: dg@enjellic.com ------------------------------------------------------------------------------ "Five year projections, are you kidding me. We don't know what we are supposed to be doing at the 4 o'clock meeting this afternoon." -- Terry Wieland Resurrection
> On Oct 26, 2020, at 3:51 AM, Dr. Greg <greg@enjellic.com> wrote: > > On Sat, Oct 24, 2020 at 08:33:21AM -0700, Andy Lutomirski wrote: > > The easiest way to generically block dynamic code loading is to not > allow the ENCLS[EAUG] instruction to be executed, the purpose of which > is to augment a defined but sparse ELRANGE with additional physical > pages from the EPC. It doesn't require ->mprotect or anything else, > just a physical decision by the OS to not allow execution of that > instruction. I’m pretty sure that one can dynamically load code without EAUG. It would require preallocation, but I can’t see why EAUG changes anything from a security policy perspective. > > All of which is consistent with my recomendation for a global disable > knob on the kernel command-line for sites that do not want to tolerate > completely anonymous code execution. > > Since this driver does not yet support EDMM, the most immediate > situation that we are dealing with are the potential security > implications of SGX2 ENCLU instructions being executed inside of an > enclave. The most principal issue is the ENCLU[EMODPE] instruction > that allows a running enclave to extend the current permissions of a > page. > > I've been assuming that Sean's desire for ->mprotect is to block the > ability of an initialized enclave, on a non-EDMM enabled driver, to > collaborate with its untrusted component to self-modify its page > permissions and thus allow execution of code that the operating system > has no visibility into. That would make far more sense then the > notion of someone trying to create an LSM that makes page by page > security decisions. If you remove every mention of EDMM from that description, and you realize that the ability for LSMs to implement this sort of policy is basically the same as for the core SGX code to do so, then I agree. The addition of EDMM will not change anything here per se, except that we’re a lot more likely to encounter enclaves doing interesting things with EMODPE once EDMM is enabled. > > The open question in all of this is that the EDMM paper, as well as > the SDM, indicate the effects of an ENCLU[EMODPE] are immediate inside > of a running enclave. I'm assuming that this does NOT mean that once > a context of execution is running in enclave mode it would be capable > of evading standard page protections but the 'immediate' is somewhat > disquieting and probably deserves clarification, despite Dave Hansen's > adament concerns about discussing the instruction... :-) If EMODPE writes an entry into the TLB that violates PTE permissions, then we have a real problem. I would be very surprised if this were to be the case.
On Mon, Oct 26, 2020 at 03:59:35PM -0700, Andy Lutomirski wrote: > > On Oct 26, 2020, at 3:51 AM, Dr. Greg <greg@enjellic.com> wrote: > > The open question in all of this is that the EDMM paper, as well as > > the SDM, indicate the effects of an ENCLU[EMODPE] are immediate inside > > of a running enclave. I'm assuming that this does NOT mean that once > > a context of execution is running in enclave mode it would be capable > > of evading standard page protections but the 'immediate' is somewhat > > disquieting and probably deserves clarification, despite Dave Hansen's > > adament concerns about discussing the instruction... :-) > > If EMODPE writes an entry into the TLB that violates PTE permissions, then we > have a real problem. I would be very surprised if this were to be the case. EMODPE only affects the EPCM, it doesn't magically change the PTEs or insert into the TLB. The "immediate" wording in the whitepaper is differentiating it from EMODPR and EMODT, where the modifications only take effect after they have been verified by the enclave via EACCEPT.
diff --git a/include/linux/mm.h b/include/linux/mm.h index 97c83773b6f0..717726fcace6 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -547,6 +547,9 @@ struct vm_operations_struct { void (*close)(struct vm_area_struct * area); int (*split)(struct vm_area_struct * area, unsigned long addr); int (*mremap)(struct vm_area_struct * area); + int (*mprotect)(struct vm_area_struct *vma, + struct vm_area_struct **pprev, unsigned long start, + unsigned long end, unsigned long newflags); vm_fault_t (*fault)(struct vm_fault *vmf); vm_fault_t (*huge_fault)(struct vm_fault *vmf, enum page_entry_size pe_size); diff --git a/mm/mprotect.c b/mm/mprotect.c index ce8b8a5eacbb..f170f3da8a4f 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -610,7 +610,10 @@ static int do_mprotect_pkey(unsigned long start, size_t len, tmp = vma->vm_end; if (tmp > end) tmp = end; - error = mprotect_fixup(vma, &prev, nstart, tmp, newflags); + if (vma->vm_ops && vma->vm_ops->mprotect) + error = vma->vm_ops->mprotect(vma, &prev, nstart, tmp, newflags); + else + error = mprotect_fixup(vma, &prev, nstart, tmp, newflags); if (error) goto out; nstart = tmp;