linux-kernel - Re: [PATCH v4 1/1] x86/sgx: Enable automatic SVN updates for SGX enclaves

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] [day] [month] [year] [list]

Message-ID: <e2b65d4d-0d82-470d-9d9d-09ebc77621f7@intel.com>
Date: Thu, 15 May 2025 08:37:53 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: "jarkko@...nel.org" <jarkko@...nel.org>,
 "seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai" <kai.huang@...el.com>,
 "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "x86@...nel.org" <x86@...nel.org>, "Mallick, Asit K"
 <asit.k.mallick@...el.com>,
 "Scarlata, Vincent R" <vincent.r.scarlata@...el.com>,
 "Cai, Chong" <chongc@...gle.com>, "Aktas, Erdem" <erdemaktas@...gle.com>,
 "Annapurve, Vishal" <vannapurve@...gle.com>,
 "dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
 "bondarn@...gle.com" <bondarn@...gle.com>,
 "Raynor, Scott" <scott.raynor@...el.com>
Subject: Re: [PATCH v4 1/1] x86/sgx: Enable automatic SVN updates for SGX
 enclaves

On 5/14/25 00:32, Reshetova, Elena wrote:
>> This was the recent discussion I am aware we had on this matter:
>> https://lkml.org/lkml/2024/2/5/1595
>> The measurements were done for older platform (skylake), but I am not
>> aware of any architectural changes since that time to improve this.
> And to make it more concrete, I made some simple tests based
> on program for stress testing rdrand/rdseed that was discussed in that
> threat earlier: https://lkml.org/lkml/2024/2/6/746 
> Using this stress testing and enough threads, I can make EUPDATESVN fail
> reliably and quite easily even with 10 time retry loop by kernel. So,
> given this, what should be the correct behaviour be here? WARN_ON
> is not justified imo. But should we return an error to userspace and
> block open()? 

No, we can't block open. Just silently fail the EUPDATESVN for now.

We can have a separate bikeshedding session about how to warn about the
failure (or not).

I can also hear Sean screaming from across the room that silent failure
is going to be really nasty to debug. Once we settle on this set, we can
have another discussion on an explicit update ABI so that folks who
truly control their environment can stop all the guests and explicitly
run EUPDATESVN at a nice convenient time. *THAT* interface can punt
retries out to userspace and warn for sure.

But, one thing at a time, please. This set will cover *normal* users:
those who don't know exactly where each SGX user is and what their
lifetimes are. Oh, and normal users also aren't under RDSEED attacks.