Intel SGX development
 help / color / mirror / Atom feed
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:58:29 -0700	[thread overview]
Message-ID: <aAwFhaqQDLXoqbmv@google.com> (raw)
In-Reply-To: <db1fd062-5a66-4942-82e2-c889dd645a7b@intel.com>

On Fri, Apr 25, 2025, Dave Hansen wrote:
> On 4/25/25 14:04, Sean Christopherson wrote:
> > Userspace is going to be waiting on ->release() no matter what.
> 
> Unless it isn't even involved and it happens automatically.

With my Google hat on: no thanks.

Customer:   Hey Google, why haven't you applied security update XYZ?
Support:    We have.
Customer:   The SVN in my attestation report says otherwise.
Support:    Let me check with engineering.
TDX team:   We applied the ucode update provided by platforms.  Platforms, what's up?
Platforms:  That's the right ucode patch.
TDX team:   Hmm, the kernel is supposed to update the SVN.  Let's bug the kernel team.
Me:         Have you guaranteed there are no active enclaves after the update?
TDX team:   Yep.
Me:         <tries to debug the problem, but it's in prod and only happens on
             some platforms>
Me:         Our theory is that enclaves haven't been fully destroyed when the
            hold is lifted.  Try adding a delay?  Maybe 1s?
TDX team:   That helped, but we still have intermittent failures.
Me:         How about 5 seconds?
TDX team:   Great, that worked!
Support:    Sorry for the delay, we're rolling out a fix, you should see the correct
            SVN shortly.
<time passes>
Customer:   Hey Google, my TDX VMs are stalled for 5 seconds during boot.
Support:    Let me check with engineering...


Is that likely to happen?  No.  Is a delay of multiple seconds likely?  Also no.
But it's not that far fetched.  And if something does go sideways, e.g. an EPC
page gets leaked, or enclave FD gets orphaned and left opened, etc., then I would
much, much prefer that the issue be visible to userspace.  Things going sideways
is inevitable; being able to take action when badness happens makes a world of
difference.

Coupled with adding latency to launching the 0=>1 enclave, just to handle something
that happens a few times per year, and I don't see any value in automatic updates.
Maybe it sounds nice on paper, but from my perspective, I see nothing but pain.

  reply	other threads:[~2025-04-25 21:58 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
2025-04-25 21:23                             ` Dave Hansen
2025-04-25 21:58                               ` Sean Christopherson [this message]
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=aAwFhaqQDLXoqbmv@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