On Mon, Aug 29, 2022 at 12:39:53PM -0400, Jason A. Donenfeld wrote: > In terms of granularity, I saw other folks suggesting making it per-task > (so, presumably, a prctl() knob), and others mentioning doing it just > for kernel crypto. For the latter, I guess the crypto API could set it > inside of its abstractions, and the various lib/crypto APIs could set it > at invocation time. I wonder, though, what's the cost of > enabling/disabling it? Would we in fact need a kind of lazy-deferred > disabling, like we have with kernel_fpu_end()? I also wonder what > crypto-adjacent code might wind up being missed if we're going function > by function. Like, obviously we'd set this for crypto_memneq, but what > about potential unprotected `==` of ID numbers that could leak some info > in various protocols? What other subtle nearby code should we be > thinking about, that relies on constant time logic but isn't neatly > folded inside a crypto_do_something() function? Another random note on this: I would hope that setting that MSR represents a speculation barrier or general instruction stream barrier, so that you can't do something naughty with the scheduler to toggle it rapidly and measure crypto timings somehow.
