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.
