From: Kai Huang <kai.huang@intel.com>
To: Haitao Huang <haitao.huang@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Sean Christopherson <seanjc@google.com>,
x86@kernel.org, linux-sgx@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [v2] x86/sgx: Allow enclaves to use Asynchrounous Exit Notification
Date: Tue, 26 Jul 2022 22:47:14 +1200 [thread overview]
Message-ID: <4c614defad8e9ce2bccce8a062600212e4978113.camel@intel.com> (raw)
In-Reply-To: <op.1pwcs8btwjvjmi@hhuan26-mobl1.mshome.net>
On Tue, 2022-07-26 at 00:10 -0500, Haitao Huang wrote:
> On Mon, 25 Jul 2022 05:36:17 -0500, Kai Huang <kai.huang@intel.com> wrote:
>
> > On Fri, 2022-07-22 at 08:21 -0700, Dave Hansen wrote:
> > > On 7/22/22 06:26, Kai Huang wrote:
> > > > Did a quick look at the spec. It appears ENCLU[EDECCSSA] should be
> > > used
> > > > together with AEX-notify. So besides advertising the new
> > > > SGX_ATTR_ASYNC_EXIT_NOTIFY bit to the KVM guest, I think we should
> > > also
> > > > advertise the ENCLU[EDECCSSA] support in guest's CPUID, like below
> > > (untested)?
> > >
> > > Sounds like a great follow-on patch! It doesn't seem truly functionally
> > > required from the spec:
> > >
> > > > EDECCSSA is a new Intel SGX user leaf function
> > > > (ENCLU[EDECCSSA]) that can facilitate AEX notification handling...
> > >
> > > If that's wrong or imprecise, I'd love to hear more about it and also
> > > about how the spec will be updated.
> > >
> >
> > They are enumerated separately, but looks in practice the notify handler
> > will
> > use it to switch back to the correct/targeted CSSA to continue to run
> > normally
> > after handling the exit notify. This is my understanding of the
> > "facilitate"
> > mean in the spec.
> >
> > Btw, in real hardware I think the two should come together, meaning no
> > real
> > hardware will only support one.
> >
> > Haitao, could you give us more information?
> >
> You are right. They are enumerated separately and HW should come with both
> or neither.
> My understanding it is also possible for enclaves choose not to receive
> AEX notify
> but still use EDECCSSA.
>
What is the use case of using EDECCSSA w/o using AEX notify?
If I understand correctly EDECCSSA effectively switches to another thread (using
the previous SSA, which is the context of another TCS thread if I understand
correctly). Won't this cause problem?
It probably makes sense to use only AEX notify w/o using EDECCSSA though, but
this should be the case that the enclave detects serious attack and don't want
to continue to run normally. In another words, it is enclave's choice, but
hardware should always support both AEX notify and EDECCSSA.
--
Thanks,
-Kai
next prev parent reply other threads:[~2022-07-26 10:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 19:13 [PATCH] [v2] x86/sgx: Allow enclaves to use Asynchrounous Exit Notification Dave Hansen
2022-07-20 19:49 ` Sean Christopherson
2022-07-20 20:02 ` Dave Hansen
2022-07-22 19:00 ` Sean Christopherson
2022-07-22 19:14 ` Dave Hansen
2022-07-22 13:26 ` Kai Huang
2022-07-22 15:21 ` Dave Hansen
2022-07-22 18:44 ` Sean Christopherson
2022-07-25 10:36 ` Kai Huang
2022-07-26 5:10 ` Haitao Huang
2022-07-26 10:47 ` Kai Huang [this message]
2022-07-26 15:28 ` Haitao Huang
2022-07-26 21:21 ` Kai Huang
2022-07-28 17:54 ` Haitao Huang
2022-07-26 15:36 ` Dave Hansen
2022-07-26 21:23 ` Kai Huang
2022-07-28 7:58 ` Jarkko Sakkinen
2022-07-29 13:28 ` Haitao Huang
2022-08-02 2:21 ` Kai Huang
2022-08-10 10:17 ` Huang, Kai
2022-08-11 1:03 ` jarkko
2022-08-11 1:57 ` Huang, Kai
2022-08-11 5:03 ` jarkko
2022-08-18 2:43 ` Huang, Kai
2022-08-03 17:14 ` Jarkko Sakkinen
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=4c614defad8e9ce2bccce8a062600212e4978113.camel@intel.com \
--to=kai.huang@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--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