Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To:     "Dave Hansen" <dave.hansen@intel.com>,
        "Dave Hansen" <dave.hansen@linux.intel.com>,
        "Kai Huang" <kai.huang@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
References: <20220720191347.1343986-1-dave.hansen@linux.intel.com>
 <ab467244dd03b5f94bafe9068b1c02790033c18c.camel@intel.com>
 <a82e840f-2030-7ab3-7160-f1b900ecdb7d@intel.com>
 <06a9fef8579e880b9b031f03911739d4d902dbe0.camel@intel.com>
 <op.1pwcs8btwjvjmi@hhuan26-mobl1.mshome.net>
 <4c614defad8e9ce2bccce8a062600212e4978113.camel@intel.com>
Date:   Tue, 26 Jul 2022 10:28:19 -0500
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From:   "Haitao Huang" <haitao.huang@linux.intel.com>
Organization: Intel Corp
Message-ID: <op.1pw6lhz8wjvjmi@hhuan26-mobl1.mshome.net>
In-Reply-To: <4c614defad8e9ce2bccce8a062600212e4978113.camel@intel.com>
User-Agent: Opera Mail/1.0 (Win32)
Precedence: bulk

On Tue, 26 Jul 2022 05:47:14 -0500, Kai Huang <kai.huang@intel.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@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?

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.

>
> 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.