- 10 10月, 2022 40 次提交
-
-
由 Kristen Carlson Accardi 提交于
mainline inclusion from mainline-5.19-rc1 commit 0c9782e2 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 0c9782e2 x86/sgx: Set active memcg prior to shmem allocation. Backport for SGX EDMM support. -------------------------------- When the system runs out of enclave memory, SGX can reclaim EPC pages by swapping to normal RAM. These backing pages are allocated via a per-enclave shared memory area. Since SGX allows unlimited over commit on EPC memory, the reclaimer thread can allocate a large number of backing RAM pages in response to EPC memory pressure. When the shared memory backing RAM allocation occurs during the reclaimer thread context, the shared memory is charged to the root memory control group, and the shmem usage of the enclave is not properly accounted for, making cgroups ineffective at limiting the amount of RAM an enclave can consume. For example, when using a cgroup to launch a set of test enclaves, the kernel does not properly account for 50% - 75% of shmem page allocations on average. In the worst case, when nearly all allocations occur during the reclaimer thread, the kernel accounts less than a percent of the amount of shmem used by the enclave's cgroup to the correct cgroup. SGX stores a list of mm_structs that are associated with an enclave. Pick one of them during reclaim and charge that mm's memcg with the shmem allocation. The one that gets picked is arbitrary, but this list almost always only has one mm. The cases where there is more than one mm with different memcg's are not worth considering. Create a new function - sgx_encl_alloc_backing(). This function is used whenever a new backing storage page needs to be allocated. Previously the same function was used for page allocation as well as retrieving a previously allocated page. Prior to backing page allocation, if there is a mm_struct associated with the enclave that is requesting the allocation, it is set as the active memory control group. [ dhansen: - fix merge conflict with ELDU fixes - check against actual ksgxd_tsk, not ->mm ] Cc: stable@vger.kernel.org Signed-off-by: NKristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NShakeel Butt <shakeelb@google.com> Acked-by: NRoman Gushchin <roman.gushchin@linux.dev> Link: https://lkml.kernel.org/r/20220520174248.4918-1-kristen@linux.intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 6507cce5 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 6507cce5 selftests/sgx: Page removal stress test. Backport for SGX EDMM support. -------------------------------- Create enclave with additional heap that consumes all physical SGX memory and then remove it. Depending on the available SGX memory this test could take a significant time to run (several minutes) as it (1) creates the enclave, (2) changes the type of every page to be trimmed, (3) enters the enclave once per page to run EACCEPT, before (4) the pages are finally removed. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/e7c6aa2ab30cb1c41e52b776958409c06970d168.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 08ceab2c category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 08ceab2c selftests/sgx: Test reclaiming of untouched page. Backport for SGX EDMM support. -------------------------------- Removing a page from an initialized enclave involves three steps: (1) the user requests changing the page type to PT_TRIM via the SGX_IOC_ENCLAVE_MODIFY_TYPES ioctl() (2) on success the ENCLU[EACCEPT] instruction is run from within the enclave to accept the page removal (3) the user initiates the actual removal of the page via the SGX_IOC_ENCLAVE_REMOVE_PAGES ioctl(). Remove a page that has never been accessed. This means that when the first ioctl() requesting page removal arrives, there will be no page table entry, yet a valid page table entry needs to exist for the ENCLU[EACCEPT] function to succeed. In this test it is verified that a page table entry can still be installed for a page that is in the process of being removed. Suggested-by: NHaitao Huang <haitao.huang@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/45e1b2a2fcd8c14597d04e40af5d8a9c1c5b017e.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 35c7e6da category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 35c7e6da selftests/sgx: Test invalid access to removed enclave page. Backport for SGX EDMM support. -------------------------------- Removing a page from an initialized enclave involves three steps: (1) the user requests changing the page type to SGX_PAGE_TYPE_TRIM via the SGX_IOC_ENCLAVE_MODIFY_TYPES ioctl(), (2) on success the ENCLU[EACCEPT] instruction is run from within the enclave to accept the page removal, (3) the user initiates the actual removal of the page via the SGX_IOC_ENCLAVE_REMOVE_PAGES ioctl(). Test two possible invalid accesses during the page removal flow: * Test the behavior when a request to remove the page by changing its type to SGX_PAGE_TYPE_TRIM completes successfully but instead of executing ENCLU[EACCEPT] from within the enclave the enclave attempts to read from the page. Even though the page is accessible from the page table entries its type is SGX_PAGE_TYPE_TRIM and thus not accessible according to SGX. The expected behavior is a page fault with the SGX flag set in the error code. * Test the behavior when the page type is changed successfully and ENCLU[EACCEPT] was run from within the enclave. The final ioctl(), SGX_IOC_ENCLAVE_REMOVE_PAGES, is omitted and replaced with an attempt to access the page. Even though the page is accessible from the page table entries its type is SGX_PAGE_TYPE_TRIM and thus not accessible according to SGX. The expected behavior is a page fault with the SGX flag set in the error code. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/189a86c25d6d62da7cfdd08ee97abc1a06fcc179.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 50b822e4 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 50b822e4 selftests/sgx: Test faulty enclave behavior. Backport for SGX EDMM support. -------------------------------- Removing a page from an initialized enclave involves three steps: first the user requests changing the page type to SGX_PAGE_TYPE_TRIM via an ioctl(), on success the ENCLU[EACCEPT] instruction needs to be run from within the enclave to accept the page removal, finally the user requests page removal to be completed via an ioctl(). Only after acceptance (ENCLU[EACCEPT]) from within the enclave can the kernel remove the page from a running enclave. Test the behavior when the user's request to change the page type succeeds, but the ENCLU[EACCEPT] instruction is not run before the ioctl() requesting page removal is run. This should not be permitted. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/fa5da30ebac108b7517194c3038b52995602b996.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 33c5aac3 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 33c5aac3 selftests/sgx: Test complete changing of page type flow. Backport for SGX EDMM support. -------------------------------- Support for changing an enclave page's type enables an initialized enclave to be expanded with support for more threads by changing the type of a regular enclave page to that of a Thread Control Structure (TCS). Additionally, being able to change a TCS or regular enclave page's type to be trimmed (SGX_PAGE_TYPE_TRIM) initiates the removal of the page from the enclave. Test changing page type to TCS as well as page removal flows in two phases: In the first phase support for a new thread is dynamically added to an initialized enclave and in the second phase the pages associated with the new thread are removed from the enclave. As an additional sanity check after the second phase the page used as a TCS page during the first phase is added back as a regular page and ensured that it can be written to (which is not possible if it was a TCS page). Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/d05b48b00338683a94dcaef9f478540fc3d6d5f9.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit b564982f category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit b564982f selftests/sgx: Introduce TCS initialization enclave operation. Backport for SGX EDMM support. -------------------------------- The Thread Control Structure (TCS) contains meta-data used by the hardware to save and restore thread specific information when entering/exiting the enclave. A TCS can be added to an initialized enclave by first adding a new regular enclave page, initializing the content of the new page from within the enclave, and then changing that page's type to a TCS. Support the initialization of a TCS from within the enclave. The variable information needed that should be provided from outside the enclave is the address of the TCS, address of the State Save Area (SSA), and the entry point that the thread should use to enter the enclave. With this information provided all needed fields of a TCS can be initialized. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/bad6052056188bde753a54313da1ac8f1e29088a.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 7eb43701 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 7eb43701 selftests/sgx: Introduce dynamic entry point. Backport for SGX EDMM support. -------------------------------- The test enclave (test_encl.elf) is built with two initialized Thread Control Structures (TCS) included in the binary. Both TCS are initialized with the same entry point, encl_entry, that correctly computes the absolute address of the stack based on the stack of each TCS that is also built into the binary. A new TCS can be added dynamically to the enclave and requires to be initialized with an entry point used to enter the enclave. Since the existing entry point, encl_entry, assumes that the TCS and its stack exists at particular offsets within the binary it is not able to handle a dynamically added TCS and its stack. Introduce a new entry point, encl_dyn_entry, that initializes the absolute address of that thread's stack to the address immediately preceding the TCS itself. It is now possible to dynamically add a contiguous memory region to the enclave with the new stack preceding the new TCS. With the new TCS initialized with encl_dyn_entry as entry point the absolute address of the stack is computed correctly on entry. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/93e9c420dedf5f773ba6965c18245bc7d62aca83.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 67f1f70a category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 67f1f70a selftests/sgx: Test two different SGX2 EAUG flows. Backport for SGX EDMM support. -------------------------------- Enclave pages can be added to an initialized enclave when an address belonging to the enclave but without a backing page is accessed from within the enclave. Accessing memory without a backing enclave page from within an enclave can be in different ways: 1) Pre-emptively run ENCLU[EACCEPT]. Since the addition of a page always needs to be accepted by the enclave via ENCLU[EACCEPT] this flow is efficient since the first execution of ENCLU[EACCEPT] triggers the addition of the page and when execution returns to the same instruction the second execution would be successful as an acceptance of the page. 2) A direct read or write. The flow where a direct read or write triggers the page addition execution cannot resume from the instruction (read/write) that triggered the fault but instead the enclave needs to be entered at a different entry point to run needed ENCLU[EACCEPT] before execution can return to the original entry point and the read/write instruction that faulted. Add tests for both flows. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/0c321e0e32790ac1de742ce5017a331e6d902ac1.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 7088c81f category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 7088c81f selftests/sgx: Add test for TCS page permission changes. Backport for SGX EDMM support. -------------------------------- Kernel should not allow permission changes on TCS pages. Add test to confirm this behavior. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/0121ad1b21befb94519072e2c18b89aa5dca00d4.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 20404a80 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 20404a80 selftests/sgx: Add test for EPCM permission changes. Backport for SGX EDMM support. -------------------------------- EPCM permission changes could be made from within (to relax permissions) or out (to restrict permissions) the enclave. Kernel support is needed when permissions are restricted to be able to call the privileged ENCLS[EMODPR] instruction. EPCM permissions can be relaxed via ENCLU[EMODPE] from within the enclave but the enclave still depends on the kernel to install PTEs with the needed permissions. Add a test that exercises a few of the enclave page permission flows: 1) Test starts with a RW (from enclave and kernel perspective) enclave page that is mapped via a RW VMA. 2) Use the SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS ioctl() to restrict the enclave (EPCM) page permissions to read-only. 3) Run ENCLU[EACCEPT] from within the enclave to accept the new page permissions. 4) Attempt to write to the enclave page from within the enclave - this should fail with a page fault on the EPCM permissions since the page table entry continues to allow RW access. 5) Restore EPCM permissions to RW by running ENCLU[EMODPE] from within the enclave. 6) Attempt to write to the enclave page from within the enclave - this should succeed since both EPCM and PTE permissions allow this access. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/2617bf2b2d1e27ca1d0096e1192ae5896baf3f80.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 629b5155 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 629b5155 Documentation/x86: Introduce enclave runtime management section. Backport for SGX EDMM support. -------------------------------- Enclave runtime management is introduced following the pattern of the section describing enclave building. Provide a brief summary of enclave runtime management, pointing to the functions implementing the ioctl()s that will contain details within their kernel-doc. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/1da0b9a938b28e68e6870ebd5291490d680e700b.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit a0506b3b category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit a0506b3b x86/sgx: Free up EPC pages directly to support large page ranges. Backport for SGX EDMM support. -------------------------------- The page reclaimer ensures availability of EPC pages across all enclaves. In support of this it runs independently from the individual enclaves in order to take locks from the different enclaves as it writes pages to swap. When needing to load a page from swap an EPC page needs to be available for its contents to be loaded into. Loading an existing enclave page from swap does not reclaim EPC pages directly if none are available, instead the reclaimer is woken when the available EPC pages are found to be below a watermark. When iterating over a large number of pages in an oversubscribed environment there is a race between the reclaimer woken up and EPC pages reclaimed fast enough for the page operations to proceed. Ensure there are EPC pages available before attempting to load a page that may potentially be pulled from swap into an available EPC page. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/a0d8f037c4a075d56bf79f432438412985f7ff7a.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 9849bb27 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 9849bb27 x86/sgx: Support complete page removal. Backport for SGX EDMM support. -------------------------------- The SGX2 page removal flow was introduced in previous patch and is as follows: 1) Change the type of the pages to be removed to SGX_PAGE_TYPE_TRIM using the ioctl() SGX_IOC_ENCLAVE_MODIFY_TYPES introduced in previous patch. 2) Approve the page removal by running ENCLU[EACCEPT] from within the enclave. 3) Initiate actual page removal using the ioctl() SGX_IOC_ENCLAVE_REMOVE_PAGES introduced here. Support the final step of the SGX2 page removal flow with ioctl() SGX_IOC_ENCLAVE_REMOVE_PAGES. With this ioctl() the user specifies a page range that should be removed. All pages in the provided range should have the SGX_PAGE_TYPE_TRIM page type and the request will fail with EPERM (Operation not permitted) if a page that does not have the correct type is encountered. Page removal can fail on any page within the provided range. Support partial success by returning the number of pages that were successfully removed. Since actual page removal will succeed even if ENCLU[EACCEPT] was not run from within the enclave the ENCLU[EMODPR] instruction with RWX permissions is used as a no-op mechanism to ensure ENCLU[EACCEPT] was successfully run from within the enclave before the enclave page is removed. If the user omits running SGX_IOC_ENCLAVE_REMOVE_PAGES the pages will still be removed when the enclave is unloaded. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Tested-by: NVijay Dhanraj <vijay.dhanraj@intel.com> Tested-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/b75ee93e96774e38bb44a24b8e9bbfb67b08b51b.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 45d546b8 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 45d546b8 x86/sgx: Support modifying SGX page type. Backport for SGX EDMM support. -------------------------------- Every enclave contains one or more Thread Control Structures (TCS). The TCS contains meta-data used by the hardware to save and restore thread specific information when entering/exiting the enclave. With SGX1 an enclave needs to be created with enough TCSs to support the largest number of threads expecting to use the enclave and enough enclave pages to meet all its anticipated memory demands. In SGX1 all pages remain in the enclave until the enclave is unloaded. SGX2 introduces a new function, ENCLS[EMODT], that is used to change the type of an enclave page from a regular (SGX_PAGE_TYPE_REG) enclave page to a TCS (SGX_PAGE_TYPE_TCS) page or change the type from a regular (SGX_PAGE_TYPE_REG) or TCS (SGX_PAGE_TYPE_TCS) page to a trimmed (SGX_PAGE_TYPE_TRIM) page (setting it up for later removal). With the existing support of dynamically adding regular enclave pages to an initialized enclave and changing the page type to TCS it is possible to dynamically increase the number of threads supported by an enclave. Changing the enclave page type to SGX_PAGE_TYPE_TRIM is the first step of dynamically removing pages from an initialized enclave. The complete page removal flow is: 1) Change the type of the pages to be removed to SGX_PAGE_TYPE_TRIM using the SGX_IOC_ENCLAVE_MODIFY_TYPES ioctl() introduced here. 2) Approve the page removal by running ENCLU[EACCEPT] from within the enclave. 3) Initiate actual page removal using the ioctl() introduced in the following patch. Add ioctl() SGX_IOC_ENCLAVE_MODIFY_TYPES to support changing SGX enclave page types within an initialized enclave. With SGX_IOC_ENCLAVE_MODIFY_TYPES the user specifies a page range and the enclave page type to be applied to all pages in the provided range. The ioctl() itself can return an error code based on failures encountered by the kernel. It is also possible for SGX specific failures to be encountered. Add a result output parameter to communicate the SGX return code. It is possible for the enclave page type change request to fail on any page within the provided range. Support partial success by returning the number of pages that were successfully changed. After the page type is changed the page continues to be accessible from the kernel perspective with page table entries and internal state. The page may be moved to swap. Any access until ENCLU[EACCEPT] will encounter a page fault with SGX flag set in error code. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Tested-by: NVijay Dhanraj <vijay.dhanraj@intel.com> Link: https://lkml.kernel.org/r/babe39318c5bf16fc65fbfb38896cdee72161575.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 7b013e72 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 7b013e72 x86/sgx: Tighten accessible memory range after enclave initialization. Backport for SGX EDMM support. -------------------------------- Before an enclave is initialized the enclave's memory range is unknown. The enclave's memory range is learned at the time it is created via the SGX_IOC_ENCLAVE_CREATE ioctl() where the provided memory range is obtained from an earlier mmap() of /dev/sgx_enclave. After an enclave is initialized its memory can be mapped into user space (mmap()) from where it can be entered at its defined entry points. With the enclave's memory range known after it is initialized there is no reason why it should be possible to map memory outside this range. Lock down access to the initialized enclave's memory range by denying any attempt to map memory outside its memory range. Locking down the memory range also makes adding pages to an initialized enclave more efficient. Pages are added to an initialized enclave by accessing memory that belongs to the enclave's memory range but not yet backed by an enclave page. If it is possible for user space to map memory that does not form part of the enclave then an access to this memory would eventually fail. Failures range from a prompt general protection fault if the access was an ENCLU[EACCEPT] from within the enclave, or a page fault via the vDSO if it was another access from within the enclave, or a SIGBUS (also resulting from a page fault) if the access was from outside the enclave. Disallowing invalid memory to be mapped in the first place avoids preventable failures. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/6391460d75ae79cea2e81eef0f6ffc03c6e9cfe7.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 5a90d2c3 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 5a90d2c3 x86/sgx: Support adding of pages to an initialized enclave. Backport for SGX EDMM support. -------------------------------- With SGX1 an enclave needs to be created with its maximum memory demands allocated. Pages cannot be added to an enclave after it is initialized. SGX2 introduces a new function, ENCLS[EAUG], that can be used to add pages to an initialized enclave. With SGX2 the enclave still needs to set aside address space for its maximum memory demands during enclave creation, but all pages need not be added before enclave initialization. Pages can be added during enclave runtime. Add support for dynamically adding pages to an initialized enclave, architecturally limited to RW permission at creation but allowed to obtain RWX permissions after trusted enclave runs EMODPE. Add pages via the page fault handler at the time an enclave address without a backing enclave page is accessed, potentially directly reclaiming pages if no free pages are available. The enclave is still required to run ENCLU[EACCEPT] on the page before it can be used. A useful flow is for the enclave to run ENCLU[EACCEPT] on an uninitialized address. This will trigger the page fault handler that will add the enclave page and return execution to the enclave to repeat the ENCLU[EACCEPT] instruction, this time successful. If the enclave accesses an uninitialized address in another way, for example by expanding the enclave stack to a page that has not yet been added, then the page fault handler would add the page on the first write but upon returning to the enclave the instruction that triggered the page fault would be repeated and since ENCLU[EACCEPT] was not run yet it would trigger a second page fault, this time with the SGX flag set in the page fault error code. This can only be recovered by entering the enclave again and directly running the ENCLU[EACCEPT] instruction on the now initialized address. Accessing an uninitialized address from outside the enclave also triggers this flow but the page will remain inaccessible (access will result in #PF) until accepted from within the enclave via ENCLU[EACCEPT]. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Tested-by: NVijay Dhanraj <vijay.dhanraj@intel.com> Link: https://lkml.kernel.org/r/a254a58eabea053803277449b24b6e4963a3883b.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit ff08530a category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit ff08530a x86/sgx: Support restricting of enclave page permissions. Backport for SGX EDMM support. -------------------------------- In the initial (SGX1) version of SGX, pages in an enclave need to be created with permissions that support all usages of the pages, from the time the enclave is initialized until it is unloaded. For example, pages used by a JIT compiler or when code needs to otherwise be relocated need to always have RWX permissions. SGX2 includes a new function ENCLS[EMODPR] that is run from the kernel and can be used to restrict the EPCM permissions of regular enclave pages within an initialized enclave. Introduce ioctl() SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS to support restricting EPCM permissions. With this ioctl() the user specifies a page range and the EPCM permissions to be applied to all pages in the provided range. ENCLS[EMODPR] is run to restrict the EPCM permissions followed by the ENCLS[ETRACK] flow that will ensure no cached linear-to-physical address mappings to the changed pages remain. It is possible for the permission change request to fail on any page within the provided range, either with an error encountered by the kernel or by the SGX hardware while running ENCLS[EMODPR]. To support partial success the ioctl() returns an error code based on failures encountered by the kernel as well as two result output parameters: one for the number of pages that were successfully changed and one for the SGX return code. The page table entry permissions are not impacted by the EPCM permission changes. VMAs and PTEs will continue to allow the maximum vetted permissions determined at the time the pages are added to the enclave. The SGX error code in a page fault will indicate if it was an EPCM permission check that prevented an access attempt. No checking is done to ensure that the permissions are actually being restricted. This is because the enclave may have relaxed the EPCM permissions from within the enclave without the kernel knowing. An attempt to relax permissions using this call will be ignored by the hardware. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Tested-by: NVijay Dhanraj <vijay.dhanraj@intel.com> Link: https://lkml.kernel.org/r/082cee986f3c1a2f4fdbf49501d7a8c5a98446f8.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit a76e7f1f category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit a76e7f1f x86/sgx: Support VA page allocation without reclaiming. Backport for SGX EDMM support. -------------------------------- struct sgx_encl should be protected with the mutex sgx_encl->lock. One exception is sgx_encl->page_cnt that is incremented (in sgx_encl_grow()) when an enclave page is added to the enclave. The reason the mutex is not held is to allow the reclaimer to be called directly if there are no EPC pages (in support of a new VA page) available at the time. Incrementing sgx_encl->page_cnt without sgc_encl->lock held is currently (before SGX2) safe from concurrent updates because all paths in which sgx_encl_grow() is called occur before enclave initialization and are protected with an atomic operation on SGX_ENCL_IOCTL. SGX2 includes support for dynamically adding pages after enclave initialization where the protection of SGX_ENCL_IOCTL is not available. Make direct reclaim of EPC pages optional when new VA pages are added to the enclave. Essentially the existing "reclaim" flag used when regular EPC pages are added to an enclave becomes available to the caller when used to allocate VA pages instead of always being "true". When adding pages without invoking the reclaimer it is possible to do so with sgx_encl->lock held, gaining its protection against concurrent updates to sgx_encl->page_cnt after enclave initialization. No functional change. Reported-by: NHaitao Huang <haitao.huang@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/42c5934c229982ee67982bb97c6ab34bde758620.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Jarkko Sakkinen 提交于
mainline inclusion from mainline-6.0-rc1 commit 8123073c category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 8123073c x86/sgx: Export sgx_encl_page_alloc(). Backport for SGX EDMM support. -------------------------------- Move sgx_encl_page_alloc() to encl.c and export it so that it can be used in the implementation for support of adding pages to initialized enclaves, which requires to allocate new enclave pages. Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Link: https://lkml.kernel.org/r/57ae71b4ea17998467670232e12d6617b95c6811.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 3a535141 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 3a535141 x86/sgx: Export sgx_encl_{grow,shrink}(). Backport for SGX EDMM support. -------------------------------- In order to use sgx_encl_{grow,shrink}() in the page augmentation code located in encl.c, export these functions. Suggested-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/d51730acf54b6565710b2261b3099517b38c2ec4.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 8cb7b502 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 8cb7b502 x86/sgx: Keep record of SGX page type. Backport for SGX EDMM support. -------------------------------- SGX2 functions are not allowed on all page types. For example, ENCLS[EMODPR] is only allowed on regular SGX enclave pages and ENCLS[EMODPT] is only allowed on TCS and regular pages. If these functions are attempted on another type of page the hardware would trigger a fault. Keep a record of the SGX page type so that there is more certainty whether an SGX2 instruction can succeed and faults can be treated as real failures. The page type is a property of struct sgx_encl_page and thus does not cover the VA page type. VA pages are maintained in separate structures and their type can be determined in a different way. The SGX2 instructions needing the page type do not operate on VA pages and this is thus not a scenario needing to be covered at this time. struct sgx_encl_page hosting this information is maintained for each enclave page so the space consumed by the struct is important. The existing sgx_encl_page->vm_max_prot_bits is already unsigned long while only using three bits. Transition to a bitfield for the two members to support the additional information without increasing the space consumed by the struct. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/a0a6939eefe7ba26514f6c49723521cde372de64.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit dda03e2c category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit dda03e2c x86/sgx: Create utility to validate user provided offset and length. Backport for SGX EDMM support. -------------------------------- User provided offset and length is validated when parsing the parameters of the SGX_IOC_ENCLAVE_ADD_PAGES ioctl(). Extract this validation (with consistent use of IS_ALIGNED) into a utility that can be used by the SGX2 ioctl()s that will also provide these values. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/767147bc100047abed47fe27c592901adfbb93a2.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit c7c6a8a6 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit c7c6a8a6 x86/sgx: Make sgx_ipi_cb() available internally. Backport for SGX EDMM support. -------------------------------- The ETRACK function followed by an IPI to all CPUs within an enclave is a common pattern with more frequent use in support of SGX2. Make the (empty) IPI callback function available internally in preparation for usage by SGX2. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/1179ed4a9c3c1c2abf49d51bfcf2c30b493181cc.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit f89c2f9b category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit f89c2f9b x86/sgx: Move PTE zap code to new sgx_zap_enclave_ptes(). Backport for SGX EDMM support. -------------------------------- The SGX reclaimer removes page table entries pointing to pages that are moved to swap. SGX2 enables changes to pages belonging to an initialized enclave, thus enclave pages may have their permission or type changed while the page is being accessed by an enclave. Supporting SGX2 requires page table entries to be removed so that any cached mappings to changed pages are removed. For example, with the ability to change enclave page types a regular enclave page may be changed to a Thread Control Structure (TCS) page that may not be accessed by an enclave. Factor out the code removing page table entries to a separate function sgx_zap_enclave_ptes(), fixing accuracy of comments in the process, and make it available to the upcoming SGX2 code. Place sgx_zap_enclave_ptes() with the rest of the enclave code in encl.c interacting with the page table since this code is no longer unique to the reclaimer. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/b010cdf01d7ce55dd0f00e883b7ccbd9db57160a.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit bdaa8799 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit bdaa8799 x86/sgx: Rename sgx_encl_ewb_cpumask() as sgx_encl_cpumask(). Backport for SGX EDMM support. -------------------------------- sgx_encl_ewb_cpumask() is no longer unique to the reclaimer where it is used during the EWB ENCLS leaf function when EPC pages are written out to main memory and sgx_encl_ewb_cpumask() is used to learn which CPUs might have executed the enclave to ensure that TLBs are cleared. Upcoming SGX2 enabling will use sgx_encl_ewb_cpumask() during the EMODPR and EMODT ENCLS leaf functions that make changes to enclave pages. The function is needed for the same reason it is used now: to learn which CPUs might have executed the enclave to ensure that TLBs no longer point to the changed pages. Rename sgx_encl_ewb_cpumask() to sgx_encl_cpumask() to reflect the broader usage. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/d4d08c449450a13d8dd3bb6c2b1af03895586d4f.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 7f391752 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 7f391752 x86/sgx: Export sgx_encl_ewb_cpumask(). Backport for SGX EDMM support. -------------------------------- Using sgx_encl_ewb_cpumask() to learn which CPUs might have executed an enclave is useful to ensure that TLBs are cleared when changes are made to enclave pages. sgx_encl_ewb_cpumask() is used within the reclaimer when an enclave page is evicted. The upcoming SGX2 support enables changes to be made to enclave pages and will require TLBs to not refer to the changed pages and thus will be needing sgx_encl_ewb_cpumask(). Relocate sgx_encl_ewb_cpumask() to be with the rest of the enclave code in encl.c now that it is no longer unique to the reclaimer. Take care to ensure that any future usage maintains the current context requirement that ETRACK has been called first. Expand the existing comments to highlight this while moving them to a more prominent location before the function. No functional change. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/05b60747fd45130cf9fc6edb1c373a69a18a22c5.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit b3fb517d category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit b3fb517d x86/sgx: Support loading enclave page without VMA permissions check. Backport for SGX EDMM support. -------------------------------- sgx_encl_load_page() is used to find and load an enclave page into enclave (EPC) memory, potentially loading it from the backing storage. Both usages of sgx_encl_load_page() are during an access to the enclave page from a VMA and thus the permissions of the VMA are considered before the enclave page is loaded. SGX2 functions operating on enclave pages belonging to an initialized enclave requiring the page to be in EPC. It is thus required to support loading enclave pages into the EPC independent from a VMA. Split the current sgx_encl_load_page() to support the two usages: A new call, sgx_encl_load_page_in_vma(), behaves exactly like the current sgx_encl_load_page() that takes VMA permissions into account, while sgx_encl_load_page() just loads an enclave page into EPC. VMA, PTE, and EPCM permissions continue to dictate whether the pages can be accessed from within an enclave. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/d4393513c1f18987c14a490bcf133bfb71a5dc43.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 61416b29 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 61416b29 x86/sgx: Add wrapper for SGX2 EAUG function. Backport for SGX EDMM support. -------------------------------- Add a wrapper for the EAUG ENCLS leaf function used to add a page to an initialized enclave. EAUG: 1) Stores all properties of the new enclave page in the SGX hardware's Enclave Page Cache Map (EPCM). 2) Sets the PENDING bit in the EPCM entry of the enclave page. This bit is cleared by the enclave by invoking ENCLU leaf function EACCEPT or EACCEPTCOPY. Access from within the enclave to the new enclave page is not possible until the PENDING bit is cleared. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/97a46754fe4764e908651df63694fb760f783d6e.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 09b38d0b category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 09b38d0b x86/sgx: Add wrapper for SGX2 EMODT function. Backport for SGX EDMM support. -------------------------------- Add a wrapper for the EMODT ENCLS leaf function used to change the type of an enclave page as maintained in the SGX hardware's Enclave Page Cache Map (EPCM). EMODT: 1) Updates the EPCM page type of the enclave page. 2) Sets the MODIFIED bit in the EPCM entry of the enclave page. This bit is reset by the enclave by invoking ENCLU leaf function EACCEPT or EACCEPTCOPY. Access from within the enclave to the enclave page is not possible while the MODIFIED bit is set. After changing the enclave page type by issuing EMODT the kernel needs to collaborate with the hardware to ensure that no logical processor continues to hold a reference to the changed page. This is required to ensure no required security checks are circumvented and is required for the enclave's EACCEPT/EACCEPTCOPY to succeed. Ensuring that no references to the changed page remain is accomplished with the ETRACK flow. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/dba63a8c0db1d510b940beee1ba2a8207efeb1f1.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 0fb2126d category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 0fb2126d x86/sgx: Add wrapper for SGX2 EMODPR function. Backport for SGX EDMM support. -------------------------------- Add a wrapper for the EMODPR ENCLS leaf function used to restrict enclave page permissions as maintained in the SGX hardware's Enclave Page Cache Map (EPCM). EMODPR: 1) Updates the EPCM permissions of an enclave page by treating the new permissions as a mask. Supplying a value that attempts to relax EPCM permissions has no effect on EPCM permissions (PR bit, see below, is changed). 2) Sets the PR bit in the EPCM entry of the enclave page to indicate that permission restriction is in progress. The bit is reset by the enclave by invoking ENCLU leaf function EACCEPT or EACCEPTCOPY. The enclave may access the page throughout the entire process if conforming to the EPCM permissions for the enclave page. After performing the permission restriction by issuing EMODPR the kernel needs to collaborate with the hardware to ensure that all logical processors sees the new restricted permissions. This is required for the enclave's EACCEPT/EACCEPTCOPY to succeed and is accomplished with the ETRACK flow. Expand enum sgx_return_code with the possible EMODPR return values. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/d15e7a769e13e4ca671fa2d0a0d3e3aec5aedbd4.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-6.0-rc1 commit 4c3f7358 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 4c3f7358 x86/sgx: Add short descriptions to ENCLS wrappers. Backport for SGX EDMM support. -------------------------------- The SGX ENCLS instruction uses EAX to specify an SGX function and may require additional registers, depending on the SGX function. ENCLS invokes the specified privileged SGX function for managing and debugging enclaves. Macros are used to wrap the ENCLS functionality and several wrappers are used to wrap the macros to make the different SGX functions accessible in the code. The wrappers of the supported SGX functions are cryptic. Add short descriptions of each as a comment. Suggested-by: NDave Hansen <dave.hansen@linux.intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/5e78a1126711cbd692d5b8132e0683873398f69e.1652137848.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-5.19-rc1 commit e3a3bbe3 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit e3a3bbe3 x86/sgx: Ensure no data in PCMD page after truncate. Backport for SGX EDMM support. -------------------------------- A PCMD (Paging Crypto MetaData) page contains the PCMD structures of enclave pages that have been encrypted and moved to the shmem backing store. When all enclave pages sharing a PCMD page are loaded in the enclave, there is no need for the PCMD page and it can be truncated from the backing store. A few issues appeared around the truncation of PCMD pages. The known issues have been addressed but the PCMD handling code could be made more robust by loudly complaining if any new issue appears in this area. Add a check that will complain with a warning if the PCMD page is not actually empty after it has been truncated. There should never be data in the PCMD page at this point since it is was just checked to be empty and truncated with enclave mutex held and is updated with the enclave mutex held. Suggested-by: NDave Hansen <dave.hansen@linux.intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Link: https://lkml.kernel.org/r/6495120fed43fafc1496d09dd23df922b9a32709.1652389823.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-5.19-rc1 commit 0e4e729a category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 0e4e729a x86/sgx: Obtain backing storage page with enclave mutex held. Backport for SGX EDMM support. -------------------------------- Haitao reported encountering a WARN triggered by the ENCLS[ELDU] instruction faulting with a #GP. The WARN is encountered when the reclaimer evicts a range of pages from the enclave when the same pages are faulted back right away. The SGX backing storage is accessed on two paths: when there are insufficient free pages in the EPC the reclaimer works to move enclave pages to the backing storage and as enclaves access pages that have been moved to the backing storage they are retrieved from there as part of page fault handling. An oversubscribed SGX system will often run the reclaimer and page fault handler concurrently and needs to ensure that the backing store is accessed safely between the reclaimer and the page fault handler. This is not the case because the reclaimer accesses the backing store without the enclave mutex while the page fault handler accesses the backing store with the enclave mutex. Consider the scenario where a page is faulted while a page sharing a PCMD page with the faulted page is being reclaimed. The consequence is a race between the reclaimer and page fault handler, the reclaimer attempting to access a PCMD at the same time it is truncated by the page fault handler. This could result in lost PCMD data. Data may still be lost if the reclaimer wins the race, this is addressed in the following patch. The reclaimer accesses pages from the backing storage without holding the enclave mutex and runs the risk of concurrently accessing the backing storage with the page fault handler that does access the backing storage with the enclave mutex held. In the scenario below a PCMD page is truncated from the backing store after all its pages have been loaded in to the enclave at the same time the PCMD page is loaded from the backing store when one of its pages are reclaimed: sgx_reclaim_pages() { sgx_vma_fault() { ... mutex_lock(&encl->lock); ... __sgx_encl_eldu() { ... if (pcmd_page_empty) { /* * EPC page being reclaimed /* * shares a PCMD page with an * PCMD page truncated * enclave page that is being * while requested from * faulted in. * reclaimer. */ */ sgx_encl_get_backing() <----------> sgx_encl_truncate_backing_page() } mutex_unlock(&encl->lock); } } In this scenario there is a race between the reclaimer and the page fault handler when the reclaimer attempts to get access to the same PCMD page that is being truncated. This could result in the reclaimer writing to the PCMD page that is then truncated, causing the PCMD data to be lost, or in a new PCMD page being allocated. The lost PCMD data may still occur after protecting the backing store access with the mutex - this is fixed in the next patch. By ensuring the backing store is accessed with the mutex held the enclave page state can be made accurate with the SGX_ENCL_PAGE_BEING_RECLAIMED flag accurately reflecting that a page is in the process of being reclaimed. Consistently protect the reclaimer's backing store access with the enclave's mutex to ensure that it can safely run concurrently with the page fault handler. Cc: stable@vger.kernel.org Fixes: 1728ab54 ("x86/sgx: Add a page reclaimer") Reported-by: NHaitao Huang <haitao.huang@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Link: https://lkml.kernel.org/r/fa2e04c561a8555bfe1f4e7adc37d60efc77387b.1652389823.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-5.19-rc1 commit 6bd42964 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 6bd42964 x86/sgx: Disconnect backing page references from dirty status. Backport for SGX EDMM support. -------------------------------- SGX uses shmem backing storage to store encrypted enclave pages and their crypto metadata when enclave pages are moved out of enclave memory. Two shmem backing storage pages are associated with each enclave page - one backing page to contain the encrypted enclave page data and one backing page (shared by a few enclave pages) to contain the crypto metadata used by the processor to verify the enclave page when it is loaded back into the enclave. sgx_encl_put_backing() is used to release references to the backing storage and, optionally, mark both backing store pages as dirty. Managing references and dirty status together in this way results in both backing store pages marked as dirty, even if only one of the backing store pages are changed. Additionally, waiting until the page reference is dropped to set the page dirty risks a race with the page fault handler that may load outdated data into the enclave when a page is faulted right after it is reclaimed. Consider what happens if the reclaimer writes a page to the backing store and the page is immediately faulted back, before the reclaimer is able to set the dirty bit of the page: sgx_reclaim_pages() { sgx_vma_fault() { ... sgx_encl_get_backing(); ... ... sgx_reclaimer_write() { mutex_lock(&encl->lock); /* Write data to backing store */ mutex_unlock(&encl->lock); } mutex_lock(&encl->lock); __sgx_encl_eldu() { ... /* * Enclave backing store * page not released * nor marked dirty - * contents may not be * up to date. */ sgx_encl_get_backing(); ... /* * Enclave data restored * from backing store * and PCMD pages that * are not up to date. * ENCLS[ELDU] faults * because of MAC or PCMD * checking failure. */ sgx_encl_put_backing(); } ... /* set page dirty */ sgx_encl_put_backing(); ... mutex_unlock(&encl->lock); } } Remove the option to sgx_encl_put_backing() to set the backing pages as dirty and set the needed pages as dirty right after receiving important data while enclave mutex is held. This ensures that the page fault handler can get up to date data from a page and prepares the code for a following change where only one of the backing pages need to be marked as dirty. Cc: stable@vger.kernel.org Fixes: 1728ab54 ("x86/sgx: Add a page reclaimer") Suggested-by: NDave Hansen <dave.hansen@linux.intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NHaitao Huang <haitao.huang@intel.com> Link: https://lore.kernel.org/linux-sgx/8922e48f-6646-c7cc-6393-7c78dcf23d23@intel.com/ Link: https://lkml.kernel.org/r/fa9f98986923f43e72ef4c6702a50b2a0b3c42e3.1652389823.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-5.17-rc5 commit e5733d8c category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit e5733d8c x86/sgx: Fix missing poison handling in reclaimer. Backport for SGX EDMM support. -------------------------------- The SGX reclaimer code lacks page poison handling in its main free path. This can lead to avoidable machine checks if a poisoned page is freed and reallocated instead of being isolated. A troublesome scenario is: 1. Machine check (#MC) occurs (asynchronous, !MF_ACTION_REQUIRED) 2. arch_memory_failure() is eventually called 3. (SGX) page->poison set to 1 4. Page is reclaimed 5. Page added to normal free lists by sgx_reclaim_pages() ^ This is the bug (poison pages should be isolated on the sgx_poison_page_list instead) 6. Page is reallocated by some innocent enclave, a second (synchronous) in-kernel #MC is induced, probably during EADD instruction. ^ This is the fallout from the bug (6) is unfortunate and can be avoided by replacing the open coded enclave page freeing code in the reclaimer with sgx_free_epc_page() to obtain support for poison page handling that includes placing the poisoned page on the correct list. Fixes: d6d261bd ("x86/sgx: Add new sgx_epc_page flag bit to mark free pages") Fixes: 992801ae ("x86/sgx: Initial poison handling for dirty and free pages") Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/dcc95eb2aaefb042527ac50d0a50738c7c160dac.1643830353.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Dave Hansen 提交于
mainline inclusion from mainline-5.17-rc1 commit 2056e298 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 2056e298 x86/sgx: Fix NULL pointer dereference on non-SGX systems. Backport for SGX EDMM support. -------------------------------- == Problem == Nathan Chancellor reported an oops when aceessing the 'sgx_total_bytes' sysfs file: https://lore.kernel.org/all/YbzhBrimHGGpddDM@archlinux-ax161/ The sysfs output code accesses the sgx_numa_nodes[] array unconditionally. However, this array is allocated during SGX initialization, which only occurs on systems where SGX is supported. If the sysfs file is accessed on systems without SGX support, sgx_numa_nodes[] is NULL and an oops occurs. == Solution == To fix this, hide the entire nodeX/x86/ attribute group on systems without SGX support using the ->is_visible attribute group callback. Unfortunately, SGX is initialized via a device_initcall() which occurs _after_ the ->is_visible() callback. Instead of moving SGX initialization earlier, call sysfs_update_group() during SGX initialization to update the group visiblility. This update requires moving the SGX sysfs code earlier in sgx/main.c. There are no code changes other than the addition of arch_update_sysfs_visibility() and a minor whitespace fixup to arch_node_attr_is_visible() which checkpatch caught. CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-sgx@vger.kernel.org Cc: x86@kernel.org Fixes: 50468e43 ("x86/sgx: Add an attribute for the amount of SGX memory in a NUMA node") Reported-by: NNathan Chancellor <nathan@kernel.org> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Tested-by: NNathan Chancellor <nathan@kernel.org> Tested-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/20220104171527.5E8416A8@davehans-spike.ostc.intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Jarkko Sakkinen 提交于
mainline inclusion from mainline-5.17-rc1 commit 50468e43 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 50468e43 x86/sgx: Add an attribute for the amount of SGX memory in a NUMA node. Backport for SGX EDMM support. This patch adds a new element into array node_dev_groups[], however, in 5.10 code the array is defined by macro ATTRIBUTE_GROUPS(node_dev). To resolve the conflict, just expand the macro without any functional change. -------------------------------- == Problem == The amount of SGX memory on a system is determined by the BIOS and it varies wildly between systems. It can be as small as dozens of MB's and as large as many GB's on servers. Just like how applications need to know how much regular RAM is available, enclave builders need to know how much SGX memory an enclave can consume. == Solution == Introduce a new sysfs file: /sys/devices/system/node/nodeX/x86/sgx_total_bytes to enumerate the amount of SGX memory available in each NUMA node. This serves the same function for SGX as /proc/meminfo or /sys/devices/system/node/nodeX/meminfo does for normal RAM. 'sgx_total_bytes' is needed today to help drive the SGX selftests. SGX-specific swap code is exercised by creating overcommitted enclaves which are larger than the physical SGX memory on the system. They currently use a CPUID-based approach which can diverge from the actual amount of SGX memory available. 'sgx_total_bytes' ensures that the selftests can work efficiently and do not attempt stupid things like creating a 100,000 MB enclave on a system with 128 MB of SGX memory. == Implementation Details == Introduce CONFIG_HAVE_ARCH_NODE_DEV_GROUP opt-in flag to expose an arch specific attribute group, and add an attribute for the amount of SGX memory in bytes to each NUMA node: == ABI Design Discussion == As opposed to the per-node ABI, a single, global ABI was considered. However, this would prevent enclaves from being able to size themselves so that they fit on a single NUMA node. Essentially, a single value would rule out NUMA optimizations for enclaves. Create a new "x86/" directory inside each "nodeX/" sysfs directory. 'sgx_total_bytes' is expected to be the first of at least a few sgx-specific files to be placed in the new directory. Just scanning /proc/meminfo, these are the no-brainers that we have for RAM, but we need for SGX: MemTotal: xxxx kB // sgx_total_bytes (implemented here) MemFree: yyyy kB // sgx_free_bytes SwapTotal: zzzz kB // sgx_swapped_bytes So, at *least* three. I think we will eventually end up needing something more along the lines of a dozen. A new directory (as opposed to being in the nodeX/ "root") directory avoids cluttering the root with several "sgx_*" files. Place the new file in a new "nodeX/x86/" directory because SGX is highly x86-specific. It is very unlikely that any other architecture (or even non-Intel x86 vendor) will ever implement SGX. Using "sgx/" as opposed to "x86/" was also considered. But, there is a real chance this can get used for other arch-specific purposes. [ dhansen: rewrite changelog ] Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20211116162116.93081-2-jarkko@kernel.orgSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-5.17-rc1 commit 379e4de9 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 379e4de9 x86/sgx: Fix minor documentation issues. Backport for SGX EDMM support. -------------------------------- The SGX documentation has a few repeated or one-off issues: * Remove capitalization from regular words in the middle of a sentence. * Remove punctuation found in the middle of a sentence. * Fix name of SGX daemon to consistently be ksgxd. * Fix typo of SGX instruction: ENIT -> EINIT [ dhansen: tweaked subject and changelog ] Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Link: https://lkml.kernel.org/r/ab99a87368eef69e3fb96f073368becff3eff874.1635529506.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-
由 Reinette Chatre 提交于
mainline inclusion from mainline-5.17-rc1 commit 688542e2 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5USAM CVE: NA Intel-SIG: commit 688542e2 selftests/sgx: Add test for multiple TCS entry. Backport for SGX EDMM support. -------------------------------- Each thread executing in an enclave is associated with a Thread Control Structure (TCS). The SGX test enclave contains two hardcoded TCS, thus supporting two threads in the enclave. Add a test to ensure it is possible to enter enclave at both entrypoints. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Acked-by: NDave Hansen <dave.hansen@linux.intel.com> Link: https://lkml.kernel.org/r/7be151a57b4c7959a2364753b995e0006efa3da1.1636997631.git.reinette.chatre@intel.comSigned-off-by: NZhiquan Li <zhiquan1.li@intel.com>
-