Messages in this thread | | | Date | Mon, 29 Aug 2022 15:05:59 -0400 | From | "Jason A. Donenfeld" <> | Subject | Re: Should Linux set the new constant-time mode CPU flags? |
| |
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.
| |