On Wed, Feb 01, 2023 at 10:09:16AM -0800, Dave Hansen wrote: > It was designed with the idea that timing-sensitive and *ONLY* > timing-sensitive code would be wrapped with DOITM. Wrapping that code > would allow the rest of the system to safely operate with fancy new > optimizations that exhibit data dependent timing. > > But, first of all, that code isn't wrapped with DOITM-prodding APIs > today. That model falls apart with current software on current DOITM > implementations. > > Second, we consider the kernel in general to be timing-sensitive enough > that we want DOITM=1 behavior in the kernel. > > Those lead software folks to set DOITM=1 on all the time. The fallout > from that is that nobody will ever use those fancy new optimizations. > If nobody can take advantage of them, silicon shouldn't be wasted on > them in the first place. > > Basically, DOITM was meant to open the door for adding fancy new > optimizations. It's a failure if it doesn't do that. It seems like it still potentially accomplishes its intended purpose even if it's opt-in. A prctl to turn it on for a particular process, or a particular process and its children, could work if that process knows it wants all the performance it can get and won't be handling data for which privilege boundaries matter. If this actually has the potential for substantial optimizations that would be worth it. But yeah, opt-out seems like a non-starter, since it'd require fixing all the cryptographic code in the world to request DOITM=1.
