From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>,
"jarkko@kernel.org" <jarkko@kernel.org>,
Kai Huang <kai.huang@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>,
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, 25 Apr 2025 14:04:35 -0700 [thread overview]
Message-ID: <aAv445Sr71NUJP1X@google.com> (raw)
In-Reply-To: <fbd2acdb-35dc-4e8c-9bd9-e84264f88648@intel.com>
On Fri, Apr 25, 2025, Dave Hansen wrote:
> On 4/25/25 12:29, Sean Christopherson wrote:
> > --- a/arch/x86/kernel/cpu/sgx/virt.c
> > +++ b/arch/x86/kernel/cpu/sgx/virt.c
> > @@ -255,6 +255,7 @@ static int sgx_vepc_release(struct inode *inode, struct file *file)
> > xa_destroy(&vepc->page_array);
> > kfree(vepc);
> >
> > + sgx_dec_usage_count();
> > return 0;
> > }
>
> ->release() is not close(). Userspace doesn't have control over when
> release() gets called, so it's a poor thing to say: "wait until all SGX
> struct files have been released, then do EUPDATESVN". At least that's
> what folks have always told me when I went poking around the VFS.
>
> That alone would make this a non-starter.
And what frees all the EPC pages? Hint: it's starts with an 'r'.
Userspace is going to be waiting on ->release() no matter what. There's no getting
around that, all enclaves and virtual EPC instances must be fully destroyed to
ensure the EPC is empty.
At least with this approach, userspace can know that the EPC is "busy", whereas
with automatic updates, userspace has zero visibility. The only breadcrumb it
would get is the SVN, which presumably can only be retrieved from within an encave.
But even if userspace can easily read the SVN, unless userspace has a priori
knowledge of the SVN it expects, userspace has no way of knowing if the SVN isn't
changing because no update was required, or if the SVN isn't changing because
the kernel can't find a window where there's no active EPC page.
Exposing -EBUSY to userspace gives it a variety of options. E.g. retry N times,
with M delay, and then force a reboot if all else fails.
If we wanted to be more explicit, it would be trivial to add a getter, but IMO
that's completely unnecessary, as it's fully redundant with the errno from the
setter.
E.g.
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index e8fcf032e842..4dc95d59c11f 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -958,14 +958,26 @@ static int sgx_update_svn(const char *buffer, const struct kernel_param *kp)
}
}
+static int sgx_can_update_svn(char *buffer, const struct kernel_param *kp)
+{
+ if (!sgx_has_eupdatesvn)
+ return sysfs_emit(buffer, "unsupported\n");
+
+ if (atomic_read(&sgx_usage_count))
+ return sysfs_emit(buffer, "busy\n");
+
+ return sysfs_emit(buffer, "ready\n");
+}
+
static const struct kernel_param_ops sgx_update_svn_ops = {
.set = sgx_update_svn,
+ .get = sgx_can_update_svn,
};
#undef MODULE_PARAM_PREFIX
#define MODULE_PARAM_PREFIX "sgx."
-device_param_cb(update_svn, &sgx_update_svn_ops, NULL, 0200);
-__MODULE_PARM_TYPE(update_svn, "bool");
+device_param_cb(update_svn, &sgx_update_svn_ops, NULL, 0644);
+__MODULE_PARM_TYPE(update_svn, "int");
static int __init sgx_init(void)
{
next prev parent reply other threads:[~2025-04-25 21:04 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
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 [this message]
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=aAv445Sr71NUJP1X@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox