linux-kernel - Re: [PATCH] [v2] x86/sgx: Allow enclaves to use Asynchrounous Exit Notification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 27 Jul 2022 09:21:53 +1200
From:   Kai Huang <kai.huang@...el.com>
To:     Haitao Huang <haitao.huang@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     Jarkko Sakkinen <jarkko@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Sean Christopherson <seanjc@...gle.com>, x86@...nel.org,
        linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [v2] x86/sgx: Allow enclaves to use Asynchrounous Exit
 Notification

On Tue, 2022-07-26 at 10:28 -0500, Haitao Huang wrote:
> On Tue, 26 Jul 2022 05:47:14 -0500, Kai Huang <kai.huang@...el.com> wrote:
> 
> > 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@...el.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?
> 
> No. Decrementing CSSA is equivalent to popping stack frames, not switching  
> threads.
> In some cases such as so-called "first stage" exception handling, one  
> could pop CSSA back to the previous after resetting CPU context and stack  
> frame appropriate to the "second stage" or "real" exception handling  
> routine, then jump to the handler directly. This could improve exception  
> handling performance by saving an EEXIT/ERESUME trip.
> 
> 

Looking at the AEX-notify spec again, EDECCSSA does below:

(* At this point, the instruction is guaranteed to complete *)
CR_TCS_PA.CSSA := CR_TCS_PA.CSSA - 1;
CR_GPR_PA := Physical_Address(DS:TMP_GPR);

It doens't reset the RIP to CR_GPA_PA.RIP so looks yes you are right.  It only
"popping the stack frame" but doesn't switch thread.

But the pseudo code of EDECCSSA only updates the CR_TCS_PA and CR_GPR_PA
registers (forget about XSAVE not), but doesn't manually updating the actual CPU
registers such as GPRs.  Are the actual CPU registers updated automatically when
CR_xx are updated?

-- 
Thanks,
-Kai