From: Sean Christopherson <seanjc@google.com>
To: Kai Huang <kai.huang@intel.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
Vincent Scarlata <vincent.r.scarlata@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"jarkko@kernel.org" <jarkko@kernel.org>,
Vishal Annapurve <vannapurve@google.com>,
Chong Cai <chongc@google.com>,
Asit K Mallick <asit.k.mallick@intel.com>,
Erdem Aktas <erdemaktas@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"bondarn@google.com" <bondarn@google.com>,
"dionnaglaze@google.com" <dionnaglaze@google.com>,
Scott Raynor <scott.raynor@intel.com>
Subject: Re: [PATCH v3 2/2] x86/sgx: Implement EUPDATESVN and opportunistically call it during first EPC page alloc
Date: Fri, 18 Apr 2025 07:18:46 -0700 [thread overview]
Message-ID: <aAJfJ38wt2bnguhg@google.com> (raw)
In-Reply-To: <6bbfb38a0cd66af3d3562a82adac835316b1f4e5.camel@intel.com>
On Thu, Apr 17, 2025, Kai Huang wrote:
> I think the sgx_updatesvn() should just return true when EUPDATESVN returns 0 or
> SGX_NO_UPDATE, and return false for all other error codes. And it should
> ENCLS_WARN() for all other error codes, except SGX_INSUFFICIENT_ENTROPY because
> it can still legally happen.
>
> Something like:
>
> do {
> ret = __eupdatesvn();
> if (ret != SGX_INSUFFICIENT_ENTROPY)
> break;
> } while (--retry);
This can be:
do {
ret = __eupdatesvn();
} while (ret == SGX_INSUFFICIENT_ENTROPY && --retry)
To make it super obvious that retry is only relevant to lack of entropy.
> if (!ret || ret == SGX_NO_UPDATE) {
> /*
> * SVN successfully updated, or it was already up-to-date.
> * Let users know when the update was successful.
> */
> if (!ret)
> pr_info("SVN updated successfully\n");
> return true;
Returning true/false is confusing since the vast majority of the SGX code uses
'0' for success. A lot of cleverness went into splicing SGX's error codes into
the kernel's -ernno; it would be a shame to ignore that :-)
E.g. this looks wrong at first (and second glance)
ret = sgx_updatesvn();
if (!ret) {
/*
* sgx_updatesvn() returned unknown error, smth
* must be broken, do not allocate a page from EPC
*/
spin_unlock(&sgx_epc_eupdatesvn_lock);
spin_unlock(&node->lock);
return NULL;
}
> }
>
> /*
> * EUPDATESVN was called when EPC is empty, all other error
> * codes are unexcepted except running out of entropy.
> */
> if (ret != SGX_INSUFFICIENT_ENTROPY)
> ENCLS_WARN(ret, "EUPDATESVN");
>
> return false;
>
>
> In __sgx_alloc_epc_page_from_node(), it should fail to allocate EPC page and
> return -ENOMEM when sgx_updatesvn() returns false. We should only allow EPC to
No, it should return a meaningful error code, not -ENOMEM. And if that's the
behavior you want, then __sgx_alloc_epc_page() should be updated to bail immediately.
The current code assuming -ENOMEM is the only failure scenario:
do {
page = __sgx_alloc_epc_page_from_node(nid);
if (page)
return page;
nid = next_node_in(nid, sgx_numa_mask);
} while (nid != nid_start);
That should be something like:
do {
page = __sgx_alloc_epc_page_from_node(nid);
if (!IS_ERR(page) || PTR_ERR(page) != -ENOMEM)
return page;
nid = next_node_in(nid, sgx_numa_mask);
} while (nid != nid_start);
> be allocated when we know the SVN is already up-to-date.
>
> Any further call of EPC allocation will trigger sgx_updatesvn() again. If it
> was failed due to unexpected error, then it should continue to fail,
> guaranteeing "sgx_alloc_epc_page() return consistently -ENOMEM, if the
> unexpected happens". If it was failed due to running out of entropy, it then
> may fail again, or it will just succeed and then SGX can continue to work.
Side topic, the function comment for __sgx_alloc_epc_page() is stale/wrong. It
returns ERR_PTR(-ENOMEM), not NULL, on failure.
/**
* __sgx_alloc_epc_page() - Allocate an EPC page
*
* Iterate through NUMA nodes and reserve ia free EPC page to the caller. Start
* from the NUMA node, where the caller is executing.
*
* Return:
* - an EPC page: A borrowed EPC pages were available.
* - NULL: Out of EPC pages.
*/
next prev parent reply other threads:[~2025-04-18 14:18 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 11:51 [PATCH v3 0/2] Enable automatic SVN updates for SGX enclaves Elena Reshetova
2025-04-15 11:51 ` [PATCH v3 1/2] x86/sgx: Use sgx_nr_used_pages for EPC page count instead of sgx_nr_free_pages Elena Reshetova
2025-04-16 10:33 ` Huang, Kai
2025-04-16 11:50 ` Reshetova, Elena
2025-04-16 18:50 ` Jarkko Sakkinen
2025-04-16 19:12 ` Jarkko Sakkinen
2025-04-15 11:51 ` [PATCH v3 2/2] x86/sgx: Implement EUPDATESVN and opportunistically call it during first EPC page alloc Elena Reshetova
2025-04-16 7:36 ` Huang, Kai
2025-04-16 12:06 ` Reshetova, Elena
2025-04-17 11:12 ` Huang, Kai
2025-04-18 14:18 ` Sean Christopherson [this message]
2025-04-22 6:58 ` Huang, Kai
2025-04-16 19:01 ` Jarkko Sakkinen
2025-04-18 14:55 ` Sean Christopherson
2025-04-22 7:23 ` Huang, Kai
2025-04-22 13:54 ` Sean Christopherson
2025-04-22 21:57 ` Huang, Kai
2025-04-24 8:34 ` Reshetova, Elena
2025-04-24 13:42 ` Sean Christopherson
2025-04-24 14:16 ` Reshetova, Elena
2025-04-24 17:19 ` Sean Christopherson
2025-04-25 6:52 ` Reshetova, Elena
2025-04-25 17:40 ` Sean Christopherson
2025-04-25 18:04 ` Dave Hansen
2025-04-25 19:29 ` Sean Christopherson
2025-04-25 20:11 ` Dave Hansen
2025-04-25 21:04 ` Sean Christopherson
2025-04-25 21:23 ` Dave Hansen
2025-04-25 21:58 ` Sean Christopherson
2025-04-25 22:07 ` Dave Hansen
2025-04-29 11:44 ` Reshetova, Elena
2025-04-29 14:46 ` Dave Hansen
2025-04-30 6:53 ` Reshetova, Elena
2025-04-30 15:16 ` Jarkko Sakkinen
2025-05-02 7:22 ` Reshetova, Elena
2025-05-02 8:56 ` Jarkko Sakkinen
2025-05-06 20:32 ` Nataliia Bondarevska
2025-04-28 6:25 ` Reshetova, Elena
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aAJfJ38wt2bnguhg@google.com \
--to=seanjc@google.com \
--cc=asit.k.mallick@intel.com \
--cc=bondarn@google.com \
--cc=chongc@google.com \
--cc=dave.hansen@intel.com \
--cc=dionnaglaze@google.com \
--cc=elena.reshetova@intel.com \
--cc=erdemaktas@google.com \
--cc=jarkko@kernel.org \
--cc=kai.huang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=scott.raynor@intel.com \
--cc=vannapurve@google.com \
--cc=vincent.r.scarlata@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.