On Fri, May 23, 2025 at 08:58:54AM -0700, Dave Hansen wrote:
> On 5/23/25 08:54, Jarkko Sakkinen wrote:
> >> +void sgx_dec_usage_count(void)
> >> +{
> >> + atomic64_dec(&sgx_usage_count);
> >> +}
> > I think these both should be static inlines in
On Thu, May 22, 2025 at 12:21:34PM +0300, Elena Reshetova wrote:
> Currently SGX does not have a global counter to count the
> active users from userspace or hypervisor. Implement such a counter,
> sgx_usage_count. It will be used by the driver when attempting
> to call EUPDATESVN SGX instruction.
On Fri, May 23, 2025 at 06:57:50PM +0300, Jarkko Sakkinen wrote:
> On Thu, May 22, 2025 at 12:21:37PM +0300, Elena Reshetova wrote:
> > All running enclaves and cryptographic assets (such as internal SGX
> > encryption keys) are assumed to be compromised whenever an SGX-relate
On Thu, May 22, 2025 at 12:21:37PM +0300, Elena Reshetova wrote:
> All running enclaves and cryptographic assets (such as internal SGX
> encryption keys) are assumed to be compromised whenever an SGX-related
> microcode update occurs. To mitigate this assumed compromise the new
> supervisor SGX ins
On Thu, May 22, 2025 at 12:21:36PM +0300, Elena Reshetova wrote:
> Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> process can know the execution state of EUPDATESVN and notify
> userspace.
>
> Signed-off-by: Elena Reshetova
> ---
> arch/x86/include/asm/sgx.h | 37 +++
On Tue, May 20, 2025 at 06:31:46AM +, Reshetova, Elena wrote:
BTW, please keep the line which tells who responded.
> > +/**
> > > + * sgx_updatesvn() - Attempt to call ENCLS[EUPDATESVN]
> > > + * If EPC is empty, this instruction attempts to update CPUSVN to the
> > > + * currently loaded mi
On Tue, May 20, 2025 at 06:25:04AM +, Reshetova, Elena wrote:
> > Maybe just use raw atomic_inc() and atomic_dec() at the sites?
> >
> > IMHO, it makes only sense to wrap, when it makes sense to wrap.
>
> You mean for this patch or overall? For overall we discussed in v4
> why we would like t
On Mon, May 19, 2025 at 10:24:31AM +0300, Elena Reshetova wrote:
> SGX enclaves have an attestation mechanism. An enclave might,
> for instance, need to attest to its state before it is given
> a special decryption key. Since SGX must trust the CPU microcode,
> attestation incorporates the microc
On Mon, May 19, 2025 at 10:24:30AM +0300, Elena Reshetova wrote:
> The SGX attestation architecture assumes a compromise
> of all running enclaves and cryptographic assets
> (like internal SGX encryption keys) whenever a microcode
> update affects SGX. To mitigate the impact of this presumed
> comp
On Mon, May 19, 2025 at 11:47:32AM +, Reshetova, Elena wrote:
> > On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > > Currently SGX does not have a global counter to count the
> > > active users from userspace or hypervisor. Implement such a counter,
> > > sgx_usage_count. It will b
On Mon, May 19, 2025 at 10:24:27AM +0300, Elena Reshetova wrote:
> Currently SGX does not have a global counter to count the
> active users from userspace or hypervisor. Implement such a counter,
> sgx_usage_count. It will be used by the driver when attempting
> to call EUPDATESVN SGX instruction.
On Wed, May 07, 2025 at 02:14:00PM +0300, Elena Reshetova wrote:
> diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> b/arch/x86/kernel/cpu/sgx/driver.c
> index 7f8d1e11dbee..669e44d61f9f 100644
> --- a/arch/x86/kernel/cpu/sgx/driver.c
> +++ b/arch/x86/kernel/cpu/sgx/driver.c
> @@ -19,6 +19,10 @@
On Fri, 2025-05-02 at 07:22 +, Reshetova, Elena wrote:
>
> >
> > On Wed, Apr 30, 2025 at 06:53:32AM +, Reshetova, Elena wrote:
> > > 2. Switch to Sean's approach to execute EUPDATESVN during the
> > sgx_open().
> > > Btw, Sean do you agree that we don't gain much doing it second
> > > tim
On Wed, Apr 30, 2025 at 06:53:32AM +, Reshetova, Elena wrote:
> 2. Switch to Sean's approach to execute EUPDATESVN during the sgx_open().
> Btw, Sean do you agree that we don't gain much doing it second time during
> release() given the microcode flow?
> I would rather leave only one invocation
On Wed, Apr 16, 2025 at 09:50:44PM +0300, Jarkko Sakkinen wrote:
> On Tue, Apr 15, 2025 at 02:51:21PM +0300, Elena Reshetova wrote:
> > Note: The serialization for sgx_nr_total_pages is not needed because
> > the variable is only updated during the initialization and there'
On Tue, Apr 15, 2025 at 02:51:21PM +0300, Elena Reshetova wrote:
> Note: The serialization for sgx_nr_total_pages is not needed because
> the variable is only updated during the initialization and there's no
> concurrent access.
No. It's
- not a side-note but core part of the rationale.
- the rea
On Tue, Apr 15, 2025 at 02:51:22PM +0300, Elena Reshetova wrote:
> SGX architecture introduced a new instruction called EUPDATESVN
> to Ice Lake. It allows updating security SVN version, given that EPC
> is completely empty. The latter is required for security reasons
> in order to reason that encl
On Tue, Apr 08, 2025 at 06:54:14AM +, Reshetova, Elena wrote:
> >
> > On Tue, Apr 08, 2025 at 09:40:14AM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Apr 08, 2025 at 12:06:32AM +, Huang, Kai wrote:
> > > > On Mon, 2025-04-07 at 08:23 +, Reshetova, Ele
On Tue, Apr 08, 2025 at 09:40:14AM +0300, Jarkko Sakkinen wrote:
> On Tue, Apr 08, 2025 at 12:06:32AM +, Huang, Kai wrote:
> > On Mon, 2025-04-07 at 08:23 +, Reshetova, Elena wrote:
> > > > On Fri, Apr 04, 2025 at 06:53:17AM +, Reshetova, Elena wrote:
> > &
On Tue, Apr 08, 2025 at 12:06:32AM +, Huang, Kai wrote:
> On Mon, 2025-04-07 at 08:23 +, Reshetova, Elena wrote:
> > > On Fri, Apr 04, 2025 at 06:53:17AM +, Reshetova, Elena wrote:
> > > > > On Wed, Apr 02, 2025 at 01:11:25PM +, Reshetova, Elena wrote:
> > > > > > > > current SGX ke
On Wed, Apr 02, 2025 at 01:11:25PM +, Reshetova, Elena wrote:
> > > current SGX kernel code does not handle such errors in any other way
> > > than notifying that operation failed for other ENCLS leaves. So, I don't
> > > see why ENCLS[EUPDATESVN] should be different from existing behaviour?
>
On Fri, Apr 04, 2025 at 06:53:17AM +, Reshetova, Elena wrote:
> > On Wed, Apr 02, 2025 at 01:11:25PM +, Reshetova, Elena wrote:
> > > > > current SGX kernel code does not handle such errors in any other way
> > > > > than notifying that operation failed for other ENCLS leaves. So, I
> > >
On Tue, Apr 01, 2025 at 09:35:33AM +, Reshetova, Elena wrote:
> > > None of these exceptional conditions are fatal or present an
> > > immediate danger to the system security. So, allowing the re-tries
> > > seems logical in this case. In case re-tries also fail, the system
> > > admin will hav
On Mon, Mar 31, 2025 at 07:26:45AM +, Reshetova, Elena wrote:
> > > > + default:
> > > > + pr_err("EUPDATESVN: unknown error %d\n", ret);
> > > > + break;
> > > > + }
> > >
> > > Overall, I think you're right in that "inversion" does make sense,
> > > now
On Fri, Mar 28, 2025 at 02:57:41PM +0200, Elena Reshetova wrote:
> SGX architecture introduced a new instruction called EUPDATESVN
> to Ice Lake. It allows updating security SVN version, given that EPC
> is completely empty. The latter is required for security reasons
> in order to reason that encl
On Fri, Mar 28, 2025 at 07:50:43PM +0200, Jarkko Sakkinen wrote:
> On Fri, Mar 28, 2025 at 02:57:41PM +0200, Elena Reshetova wrote:
> > SGX architecture introduced a new instruction called EUPDATESVN
> > to Ice Lake. It allows updating security SVN version, given that EPC
> >
On Fri, Mar 28, 2025 at 10:42:18AM +0200, Jarkko Sakkinen wrote:
> In your code example you had a loop inside spinlock, which was based on
> a return code of an opcode, i.e. potentially infinite loop.
>
> I'd like to remind you that the hardware I have is NUC7 from 2018 so
>
On Fri, Mar 28, 2025 at 08:27:51AM +, Reshetova, Elena wrote:
>
> > On Thu, Mar 27, 2025 at 03:42:30PM +, Reshetova, Elena wrote:
> > > > > > > + case SGX_NO_UPDATE:
> > > > > > > + pr_debug("EUPDATESVN was successful, but CPUSVN
> > was not
> > > > > > updated, "
> > > > > > > +
On Fri, Mar 28, 2025 at 08:07:24AM +, Reshetova, Elena wrote:
> > Yes but obviously I cannot promise that I'll accept this as it is
> > until I see the final version
>
> Are you saying you prefer *this version with spinlock* vs.
> simpler version that utilizes the fact that sgx_nr_free_pages
oN Thu, Mar 27, 2025 at 03:29:53PM +, Reshetova, Elena wrote:
>
> > On Mon, Mar 24, 2025 at 12:12:41PM +, Reshetova, Elena wrote:
> > > > On Fri, Mar 21, 2025 at 02:34:40PM +0200, Elena Reshetova wrote:
> > > > > In order to successfully execute ENCLS[EUPDATESVN], EPC must be
> > empty.
>
On Thu, Mar 27, 2025 at 03:31:31PM +, Reshetova, Elena wrote:
> > On Mon, Mar 24, 2025 at 12:19:37PM +, Reshetova, Elena wrote:
> > >
> > > > On Fri, Mar 21, 2025 at 02:34:41PM +0200, Elena Reshetova wrote:
> > > > > sgx_nr_free_pages is an atomic that is used to keep track of
> > > > > fre
On Thu, Mar 27, 2025 at 03:42:30PM +, Reshetova, Elena wrote:
> > > > > + case SGX_NO_UPDATE:
> > > > > + pr_debug("EUPDATESVN was successful, but CPUSVN was not
> > > > updated, "
> > > > > + "because current SVN was not newer than
> > > > CPUSVN.\n");
> > >
On Mon, Mar 24, 2025 at 12:19:37PM +, Reshetova, Elena wrote:
>
> > On Fri, Mar 21, 2025 at 02:34:41PM +0200, Elena Reshetova wrote:
> > > sgx_nr_free_pages is an atomic that is used to keep track of
> > > free EPC pages and detect whenever page reclaiming should start.
> > > Since successful
On Mon, Mar 24, 2025 at 12:26:38PM +, Reshetova, Elena wrote:
>
> > On Fri, Mar 21, 2025 at 02:34:43PM +0200, Elena Reshetova wrote:
> > > SGX architecture introduced a new instruction called EUPDATESVN [1]
> > > to Ice Lake. It allows updating security SVN version, given that EPC
> > > is co
On Mon, Mar 24, 2025 at 12:21:14PM +, Reshetova, Elena wrote:
>
>
> > On Fri, Mar 21, 2025 at 02:34:42PM +0200, Elena Reshetova wrote:
> > > Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> > > process can know the execution state of EUPDATESVN.
> > >
> >
> > Enumerate the err
On Mon, Mar 24, 2025 at 12:12:41PM +, Reshetova, Elena wrote:
> > On Fri, Mar 21, 2025 at 02:34:40PM +0200, Elena Reshetova wrote:
> > > In order to successfully execute ENCLS[EUPDATESVN], EPC must be empty.
> > > SGX already has a variable sgx_nr_free_pages that tracks free
> > > EPC pages. Ad
On Fri, Mar 21, 2025 at 02:34:41PM +0200, Elena Reshetova wrote:
> sgx_nr_free_pages is an atomic that is used to keep track of
> free EPC pages and detect whenever page reclaiming should start.
> Since successful execution of ENCLS[EUPDATESVN] requires empty
> EPC and a fast way of checking for th
On Fri, Mar 21, 2025 at 02:34:43PM +0200, Elena Reshetova wrote:
> SGX architecture introduced a new instruction called EUPDATESVN [1]
> to Ice Lake. It allows updating security SVN version, given that EPC
> is completely empty. The latter is required for security reasons
> in order to reason that
On Fri, Mar 21, 2025 at 02:34:40PM +0200, Elena Reshetova wrote:
> In order to successfully execute ENCLS[EUPDATESVN], EPC must be empty.
> SGX already has a variable sgx_nr_free_pages that tracks free
> EPC pages. Add a new variable, sgx_nr_total_pages, that will keep
> track of total number of EP
On Fri, Mar 21, 2025 at 02:34:42PM +0200, Elena Reshetova wrote:
> Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> process can know the execution state of EUPDATESVN.
>
Enumerate the error codes. Do we need all of the three added?
> Code is from previous submission in
> https://
On Sun, Mar 09, 2025 at 05:58:06PM +0100, Vladis Dronov wrote:
> A kernel requires X86_FEATURE_SGX_LC to be able to create SGX enclaves.
> There is quite a number of hardware which has X86_FEATURE_SGX but not
> X86_FEATURE_SGX_LC. A kernel running on such a hardware does not create
> /dev/sgx* devi
: 888d24911787 ("x86/sgx: Add SGX_IOC_ENCLAVE_CREATE")
Reported-by: Dan Carpenter
Closes:
https://lore.kernel.org/linux-sgx/c87e01a0-e7dd-4749-a348-0980d3444f04@stanley.mountain/
Signed-off-by: Jarkko Sakkinen
---
v3: Updated the commit message according to Dave's suggestion and added
On Tue, Mar 04, 2025 at 03:30:54PM -0800, Dave Hansen wrote:
> On 3/4/25 14:56, Jarkko Sakkinen wrote:
> > The total size calculated for EPC can overflow u64 given the added up page
> > for SECS. Further, the total size calculated for shmem can overflow even
> > when the
adding the necessary validation for each partial results
before going forward. Return -E2BIG when an overflow is detected.
Reported-by: Dan Carpenter
Closes:
https://lore.kernel.org/linux-sgx/c87e01a0-e7dd-4749-a348-0980d3444f04@stanley.mountain/
Signed-off-by: Jarkko Sakkinen
---
arch/x86
On Tue, Feb 11, 2025 at 03:31:54PM -0800, Dave Hansen wrote:
> On 2/11/25 13:18, Huang, Kai wrote:
> >>> This requires low-level SGX implementation knowledge to fully
> >>> understand. Both what "ETRACK, EBLOCK and EWB" are in the first place,
> >>> how they are involved in reclaim and also why ERE
On Wed, Feb 12, 2025 at 10:18:11AM +1300, Huang, Kai wrote:
>
>
> On 12/02/2025 10:03 am, Jarkko Sakkinen wrote:
> > On Tue, Feb 11, 2025 at 08:25:58AM -0800, Dave Hansen wrote:
> > > > arch_memory_failure() but stay on sgx_active_page_list.
> > > > page-
On Tue, Feb 11, 2025 at 08:25:58AM -0800, Dave Hansen wrote:
> > arch_memory_failure() but stay on sgx_active_page_list.
> > page->poison is not checked in the reclaimer logic meaning that a page
> > could be
> > reclaimed and go through ETRACK, EBLOCK and EWB. This can lead to the
> > firmware r
tracking reclaimable pages in LRU
> > x86/sgx: Implement async reclamation for cgroup
> > x86/sgx: Turn on per-cgroup EPC reclamation
> >
> > Sean Christopherson (2):
> > x86/sgx: Add sgx_epc_lru_list to encapsulate LRU list
> > Docs/x86/sgx: Add description for cgroup support
> >
> > Documentation/arch/x86/sgx.rst| 83
> > arch/x86/kernel/cpu/sgx/Makefile | 1 +
> > arch/x86/kernel/cpu/sgx/encl.c| 41 +-
> > arch/x86/kernel/cpu/sgx/encl.h| 7 +-
> > arch/x86/kernel/cpu/sgx/epc_cgroup.c | 441 ++
> > arch/x86/kernel/cpu/sgx/epc_cgroup.h | 106 +
> > arch/x86/kernel/cpu/sgx/ioctl.c | 10 +-
> > arch/x86/kernel/cpu/sgx/main.c| 220 ++---
> > arch/x86/kernel/cpu/sgx/sgx.h | 54 ++-
> > arch/x86/kernel/cpu/sgx/virt.c| 2 +-
> > include/linux/misc_cgroup.h | 41 ++
> > kernel/cgroup/misc.c | 112 -
> > tools/testing/selftests/sgx/Makefile | 3 +-
> > tools/testing/selftests/sgx/README| 109 +
> > tools/testing/selftests/sgx/ash_cgexec.sh | 16 +
> > tools/testing/selftests/sgx/config| 4 +
> > .../selftests/sgx/run_epc_cg_selftests.sh | 294
> > tools/testing/selftests/sgx/settings | 2 +
> > .../selftests/sgx/watch_misc_for_tests.sh | 11 +
> > 19 files changed, 1446 insertions(+), 111 deletions(-)
> > create mode 100644 arch/x86/kernel/cpu/sgx/epc_cgroup.c
> > create mode 100644 arch/x86/kernel/cpu/sgx/epc_cgroup.h
> > create mode 100644 tools/testing/selftests/sgx/README
> > create mode 100755 tools/testing/selftests/sgx/ash_cgexec.sh
> > create mode 100644 tools/testing/selftests/sgx/config
> > create mode 100755 tools/testing/selftests/sgx/run_epc_cg_selftests.sh
> > create mode 100644 tools/testing/selftests/sgx/settings
> > create mode 100755 tools/testing/selftests/sgx/watch_misc_for_tests.sh
> >
> >
> > base-commit: 5be63fc19fcaa4c236b307420483578a56986a37
> > --
> > 2.43.0
>
> >
If there was any missing my tag:
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
>pages) {
> memunmap(section->virt_addr);
> return false;
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
ate a bug in a user space application), but it gives a consistent
> rule: if an enclave page is under certain operation by the kernel with
> the mapping removed, then other threads trying to access that page are
> temporarily blocked and should retry.
>
> Fixes: 9849bb27152c1 ("x86/sgx
at would need to be done
automatically if this happens? With a tracepoint you could react to such
even but I'm totally fine with this.
> + }
> +
> return true;
> }
>
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
> if (page)
> return page;
> - }
> +
> + nid = next_node_in(nid, sgx_numa_mask);
> + } while (nid != nid_start);
>
> return ERR_PTR(-ENOMEM);
> }
Looks good to me:
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Wed Sep 4, 2024 at 4:39 AM EEST, Aaron Lu wrote:
> On Tue, Sep 03, 2024 at 07:05:40PM +0300, Jarkko Sakkinen wrote:
> > On Fri Aug 30, 2024 at 9:14 AM EEST, Aaron Lu wrote:
> > > On Thu, Aug 29, 2024 at 07:44:13PM +0300, Jarkko Sakkinen wrote:
> > > > On Thu Aug 2
On Fri Aug 30, 2024 at 9:14 AM EEST, Aaron Lu wrote:
> On Thu, Aug 29, 2024 at 07:44:13PM +0300, Jarkko Sakkinen wrote:
> > On Thu Aug 29, 2024 at 5:38 AM EEST, Aaron Lu wrote:
> > > When current node doesn't have a EPC section configured by firmware and
> > > a
On Thu Aug 29, 2024 at 5:38 AM EEST, Aaron Lu wrote:
> When current node doesn't have a EPC section configured by firmware and
> all other EPC sections memory are used up, CPU can stuck inside the
> while loop in __sgx_alloc_epc_page() forever and soft lockup will happen.
> Note how nid_of_current
etric is concatenated in a way that @low bits 12-31 define the
> * bits 12-31 of the metric and @high bits 0-19 define the bits 32-51 of the
> * metric.
>
> base-commit: e77f8f275278886d05ce6dfe9e3bc854e7bf0713
Agreed, that has went there probably by plain mistake. Do not think it
has been intentional...
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
sgx_mark_page_reclaimable(entry->epc_page);
> }
> @@ -1141,7 +1151,14 @@ static long sgx_encl_remove_pages(struct sgx_encl
> *encl,
> /*
>* Do not keep encl->lock because of dependency on
>* mmap_lock acquired in sgx_zap_enclave_ptes().
> + *
> + * Releasing encl->lock leads to a data race: while CPU1
> + * performs sgx_zap_enclave_ptes() and removes the PTE entry
> + * for the enclave page, CPU2 may attempt to load this page
> + * (because the page is still in enclave's xarray). To prevent
> + * CPU2 from loading the page, mark the page as busy.
>*/
> + entry->desc |= SGX_ENCL_PAGE_BUSY;
> mutex_unlock(&encl->lock);
>
> sgx_zap_enclave_ptes(encl, addr);
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
_out_eaug;
>
> encl_page->encl = encl;
> encl_page->epc_page = epc_page;
> @@ -408,20 +414,20 @@ static vm_fault_t sgx_encl_eaug_page(struct
> vm_area_struct *vma,
> mutex_unlock(&encl->lock);
> return VM_FAULT_SIGBUS;
> }
> +done:
> mutex_unlock(&encl->lock);
> return VM_FAULT_NOPAGE;
>
> -err_out:
> +err_out_eaug:
> xa_erase(&encl->page_array, PFN_DOWN(encl_page->desc));
> -
> err_out_shrink:
> sgx_encl_shrink(encl, va_page);
> err_out_epc:
> sgx_encl_free_epc_page(epc_page);
> +err_out_encl:
> + kfree(encl_page);
> err_out_unlock:
> mutex_unlock(&encl->lock);
> - kfree(encl_page);
> -
> return vmret;
> }
>
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
>
> - encl_page->desc &= ~SGX_ENCL_PAGE_BEING_RECLAIMED;
> + encl_page->desc &= ~(SGX_ENCL_PAGE_BUSY | SGX_ENCL_PAGE_PCMD_BUSY);
>
> va_page = list_first_entry(&encl->va_pages, struct sgx_va_page,
> list);
> @@ -340,7 +340,7 @@ static void sgx_reclaim_pages(void)
> goto skip;
> }
>
> - encl_page->desc |= SGX_ENCL_PAGE_BEING_RECLAIMED;
> + encl_page->desc |= SGX_ENCL_PAGE_BUSY | SGX_ENCL_PAGE_PCMD_BUSY;
> mutex_unlock(&encl_page->encl->lock);
> continue;
>
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Wed Aug 21, 2024 at 4:53 AM EEST, Haitao Huang wrote:
> SGX Enclave Page Cache (EPC) memory allocations are separate from normal
> RAM allocations, and are managed solely by the SGX subsystem. The existing
> cgroup memory controller cannot be used to limit or account for SGX EPC
> memory, which
{
> + /* Reduce chance of per-cgroup reclamation for later allocation */
> + sgx_cgroup_reclaim_direct();
> +
> + /* Reduce chance of the global reclamation for later allocation */
> if (sgx_should_reclaim_global(SGX_NR_LOW_PAGES))
> sgx_reclaim_pages_global(current->mm);
> }
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
escendants, and then do the
> actual reclaim in one batch. But this is unnecessarily complicated at
> this stage to address such rare cases.
>
> Signed-off-by: Haitao Huang
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
rson
> Signed-off-by: Sean Christopherson
> Signed-off-by: Kristen Carlson Accardi
> Co-developed-by: Haitao Huang
> Signed-off-by: Haitao Huang
> Tested-by: Jarkko Sakkinen
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
us and preemptive reclamation.
>
> Note all reclaimable EPC pages are still tracked in the global LRU thus
> no per-cgroup reclamation is actually active at the moment: -ENOMEM is
> returned by __sgx_cgroup_try_charge() when LRUs are empty. Per-cgroup
> tracking and reclamation wi
d-by: Kristen Carlson Accardi
> Signed-off-by: Kristen Carlson Accardi
> Signed-off-by: Haitao Huang
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Thu Aug 15, 2024 at 9:34 PM EEST, Jarkko Sakkinen wrote:
> On Mon Aug 12, 2024 at 11:25 AM EEST, Dmitrii Kuvaiskii wrote:
> > On Wed, Jul 17, 2024 at 01:38:59PM +0300, Jarkko Sakkinen wrote:
> >
> > > Ditto.
> >
> > Just to be sure: I assume this means
On Mon Aug 12, 2024 at 11:25 AM EEST, Dmitrii Kuvaiskii wrote:
> On Wed, Jul 17, 2024 at 01:38:59PM +0300, Jarkko Sakkinen wrote:
>
> > Ditto.
>
> Just to be sure: I assume this means "Fixes should be in the head of the
> series so please reorder"? If yes, please
On Mon Aug 12, 2024 at 11:21 AM EEST, Dmitrii Kuvaiskii wrote:
> On Wed, Jul 17, 2024 at 01:38:37PM +0300, Jarkko Sakkinen wrote:
>
> > Fixes should be in the head of the series so please reorder.
>
> Do you mean that the preparation patch [1] should be applied after the two
On Mon Aug 12, 2024 at 11:16 AM EEST, Dmitrii Kuvaiskii wrote:
> On Wed, Jul 17, 2024 at 01:37:39PM +0300, Jarkko Sakkinen wrote:
> > On Fri Jul 5, 2024 at 10:45 AM EEST, Dmitrii Kuvaiskii wrote:
> > > +/*
> > > + * 'desc' bit indicating that PCMD page assoc
On Mon Aug 12, 2024 at 11:12 AM EEST, Dmitrii Kuvaiskii wrote:
> On Wed, Jul 17, 2024 at 01:36:08PM +0300, Jarkko Sakkinen wrote:
> > On Fri Jul 5, 2024 at 10:45 AM EEST, Dmitrii Kuvaiskii wrote:
> > > SGX_ENCL_PAGE_BEING_RECLAIMED flag is set when the enclave page is being
>
On Fri Jul 5, 2024 at 10:45 AM EEST, Dmitrii Kuvaiskii wrote:
> Two enclave threads may try to add and remove the same enclave page
> simultaneously (e.g., if the SGX runtime supports both lazy allocation
> and MADV_DONTNEED semantics). Consider some enclave page added to the
> enclave. User space
ock);
> /*
> * *BUG*: SIGBUS is returned
> * for a valid enclave page
> */
> return VM_FAULT_SIGBUS;
> }
> }
>
> Fixes: 5a90d2c3f5ef ("x86/sgx: Support adding of pages to an initialized
> enclave")
> Cc: sta...@vger.kernel.org
>
On Fri Jul 5, 2024 at 10:45 AM EEST, Dmitrii Kuvaiskii wrote:
> +/*
> + * 'desc' bit indicating that PCMD page associated with the enclave page is
> + * busy (e.g. because the enclave page is being reclaimed).
> + */
> +#define SGX_ENCL_PAGE_PCMD_BUSY BIT(3)
What are other situations when thi
On Fri Jul 5, 2024 at 10:45 AM EEST, Dmitrii Kuvaiskii wrote:
> SGX_ENCL_PAGE_BEING_RECLAIMED flag is set when the enclave page is being
> reclaimed (moved to the backing store). This flag however has two
> logical meanings:
side-effects
Missing the actor.
"The page r
On Fri Jul 5, 2024 at 10:45 AM EEST, Dmitrii Kuvaiskii wrote:
> SGX runtimes such as Gramine may implement EDMM-based lazy allocation of
> enclave pages and may support MADV_DONTNEED semantics [1]. The former
> implies #PF-based page allocation, and the latter implies the usage of
> SGX_IOC_ENCLAVE
On Thu Jun 6, 2024 at 9:20 AM EEST, Jarkko Sakkinen wrote:
> > There are existing code where BUG_ON() is used during the kernel early
> > boot code when memory allocation fails (e.g., see cgroup_init_subsys()),
> > so it might be acceptable to use BUG_ON() here, but it's
On Thu Jun 6, 2024 at 1:30 AM EEST, Huang, Kai wrote:
>
> >> Reorg:
> >>
> >> void sgx_cgroup_init(void)
> >> {
> >> struct workqueue_struct *wq;
> >>
> >> /* eagerly allocate the workqueue: */
> >> wq = alloc_workqueue("sgx_cg_wq", wq_unbound | wq_freezable,
> >> wq_unbound_max_active
On Wed Jun 5, 2024 at 6:33 PM EEST, Haitao Huang wrote:
> sgx_cgroup_try_charge() expects sgx_cg_wq, so it would break unless we
> check and return 0 which was the initially implemented in v12. But then
> Kai had some concern on that we expose all the interface files to allow
> user to set l
ludes a test with low mem_cg limit and large sgx_epc
> limit to verify that the RAM used for per-cgroup reclamation is charged
> to a proper mem_cg. For this test, it turns off swapping before start,
> and turns swapping back on afterwards.
>
> Add README to document how to run the te
On Thu May 16, 2024 at 1:29 AM EEST, Haitao Huang wrote:
> On Wed, 15 May 2024 16:55:59 -0500, Haitao Huang
> wrote:
>
> > On Wed, 15 May 2024 01:55:21 -0500, Bojun Zhu
> > wrote:
> >
> >> EDMM's ioctl()s support batch operations, which may be
> >> time-consuming. Try to explicitly give up th
On Thu May 16, 2024 at 12:55 AM EEST, Haitao Huang wrote:
> On Wed, 15 May 2024 01:55:21 -0500, Bojun Zhu
> wrote:
>
> > EDMM's ioctl()s support batch operations, which may be
> > time-consuming. Try to explicitly give up the CPU as the prefix
> > operation at the every begin of "for loop" in
>
> Thank you very much. I understand the changelog is still being discussed
> and those changes look good to me, to which you can add:
>
> Reviewed-by: Reinette Chatre
also for this (with changelog tweak Dave suggested) so that we don't
need a new round:
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
/cpu/sgx/ioctl.c
> index b65ab214bdf5..c542d4dd3e64 100644
> --- a/arch/x86/kernel/cpu/sgx/ioctl.c
> +++ b/arch/x86/kernel/cpu/sgx/ioctl.c
> @@ -1142,6 +1142,7 @@ static long sgx_encl_remove_pages(struct sgx_encl *encl,
>* Do not keep encl->lock because of dependency on
>* mmap_lock acquired in sgx_zap_enclave_ptes().
>*/
> + entry->desc |= SGX_ENCL_PAGE_BEING_REMOVED;
> mutex_unlock(&encl->lock);
>
> sgx_zap_enclave_ptes(encl, addr);
Makes perfect sense:
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Wed May 15, 2024 at 5:15 PM EEST, Dave Hansen wrote:
> On 5/15/24 06:54, Jarkko Sakkinen wrote:
> > I'd cut out 90% of the description out and just make the argument of
> > the wrong error code, and done. The sequence is great for showing
> > how this could happen. Th
On Wed May 15, 2024 at 4:54 PM EEST, Jarkko Sakkinen wrote:
> On Wed May 15, 2024 at 4:12 PM EEST, Dmitrii Kuvaiskii wrote:
> > diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> > index 279148e72459..41f14b1a3025 100644
> > --- a/arch/x86/
On Wed May 15, 2024 at 4:12 PM EEST, Dmitrii Kuvaiskii wrote:
> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> index 279148e72459..41f14b1a3025 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -382,8 +382,11 @@ static vm_fault
2s!
> ...
> RIP: 0010:sgx_enclave_restrict_permissions+0xba/0x1f0
> ...
> Call Trace:
> sgx_ioctl
> __x64_sys_ioctl
> x64_sys_call
> do_syscall_64
> entry_SYSCALL_64_after_hwframe
> [ end trace ]
>
AGE))
> return addr;
> @@ -2334,8 +2333,8 @@ unsigned long shmem_get_unmapped_area(struct file *file,
> if (inflated_len < len)
> return addr;
>
> - inflated_addr = mm_get_unmapped_area(current->mm, NULL, uaddr,
> - inflated_len, 0, flags);
> + inflated_addr = current_get_unmapped_area(NULL, uaddr,
> + inflated_len, 0, flags);
> if (IS_ERR_VALUE(inflated_addr))
> return addr;
> if (inflated_addr & ~PAGE_MASK)
> @@ -4799,7 +4798,7 @@ unsigned long shmem_get_unmapped_area(struct file *file,
> unsigned long addr, unsigned long len,
> unsigned long pgoff, unsigned long flags)
> {
> - return mm_get_unmapped_area(current->mm, file, addr, len, pgoff, flags);
> + return current_get_unmapped_area(file, addr, len, pgoff, flags);
> }
> #endif
>
>
> base-commit: 9221b2819b8a4196eecf5476d66201be60fbcf29
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Tue Apr 30, 2024 at 10:51 PM EEST, Haitao Huang wrote:
> With different cgroups, the script starts one or multiple concurrent SGX
> selftests (test_sgx), each to run the unclobbered_vdso_oversubscribed
> test case, which loads an enclave of EPC size equal to the EPC capacity
> available on the p
On Mon Apr 29, 2024 at 7:18 PM EEST, Haitao Huang wrote:
> Hi Jarkko
>
> On Sun, 28 Apr 2024 17:03:17 -0500, Jarkko Sakkinen
> wrote:
>
> > On Fri Apr 26, 2024 at 5:28 PM EEST, Dave Hansen wrote:
> >> On 4/16/24 07:15, Jarkko Sakkinen wrote:
> >> >
On Mon Apr 29, 2024 at 1:43 PM EEST, Dmitrii Kuvaiskii wrote:
> Two enclave threads may try to add and remove the same enclave page
> simultaneously (e.g., if the SGX runtime supports both lazy allocation
> and `MADV_DONTNEED` semantics). Consider this race:
>
> 1. T1 performs page removal in sgx_e
On Mon Apr 29, 2024 at 4:22 PM EEST, Jarkko Sakkinen wrote:
> On Mon Apr 29, 2024 at 4:04 PM EEST, Jarkko Sakkinen wrote:
> > > Fix these two bugs (1) by returning VM_FAULT_NOPAGE to the generic Linux
> > > fault handler so that no signal is sent to userspace, and (
On Mon Apr 29, 2024 at 4:04 PM EEST, Jarkko Sakkinen wrote:
> > Fix these two bugs (1) by returning VM_FAULT_NOPAGE to the generic Linux
> > fault handler so that no signal is sent to userspace, and (2) by
> > replacing sgx_encl_free_epc_page() with sgx_free_epc_page() so that
On Mon Apr 29, 2024 at 1:43 PM EEST, Dmitrii Kuvaiskii wrote:
> SGX runtimes such as Gramine may implement EDMM-based lazy allocation of
> enclave pages and may support MADV_DONTNEED semantics [1]. The former
> implies #PF-based page allocation, and the latter implies the usage of
> SGX_IOC_ENCLAVE
On Mon Apr 29, 2024 at 1:43 PM EEST, Dmitrii Kuvaiskii wrote:
> Two enclave threads may try to access the same non-present enclave page
> simultaneously (e.g., if the SGX runtime supports lazy allocation). The
> threads will end up in sgx_encl_eaug_page(), racing to acquire the
> enclave lock. The
On Fri Apr 26, 2024 at 5:18 PM EEST, Bojun Zhu wrote:
> EDMM's ioctl()s support batch operations, which may be
> time-consuming. Try to explicitly give up the CPU as the prefix
> operation at the every begin of "for loop" in
> sgx_enclave_{ modify_types | restrict_permissions | remove_pages}
> to g
On Fri Apr 26, 2024 at 5:28 PM EEST, Dave Hansen wrote:
> On 4/16/24 07:15, Jarkko Sakkinen wrote:
> > On Tue Apr 16, 2024 at 8:42 AM EEST, Huang, Kai wrote:
> > Yes, exactly. I'd take one week break and cycle the kselftest part
> > internally a bit as I said my previo
On Wed Apr 24, 2024 at 10:42 PM EEST, Haitao Huang wrote:
> Hi Jarkko
> On Tue, 16 Apr 2024 11:08:11 -0500, Jarkko Sakkinen
> wrote:
>
> > On Tue Apr 16, 2024 at 5:54 PM EEST, Haitao Huang wrote:
> >> I did declare the configs in the config file but I missed it
On Wed Apr 24, 2024 at 8:44 PM EEST, Jarkko Sakkinen wrote:
> On Wed Apr 24, 2024 at 2:50 PM EEST, Bojun Zhu wrote:
> > I still have some questions:
> >
> > It seems that the variable "ret" is set to 0 if there is **some** EPC pages
> > have been
> >
On Wed Apr 24, 2024 at 2:50 PM EEST, Bojun Zhu wrote:
> I still have some questions:
>
> It seems that the variable "ret" is set to 0 if there is **some** EPC pages
> have been
> added when interrupted by signal(Supposed that sgx_encl_add_page()
> always returns successfully).
Ah, ok.
Returnin
1 - 100 of 1228 matches
Mail list logo
