Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 29 Aug 2022 15:05:59 -0400
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     x86@kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
        Adam Langley <agl@google.com>, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: Should Linux set the new constant-time mode CPU flags?
Message-ID: <Yw0OF89auWTh12Xd@zx2c4.com>
References: <YwgCrqutxmX0W72r@gmail.com>
 <Ywzr2d52ixYXUDWR@zx2c4.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <Ywzr2d52ixYXUDWR@zx2c4.com>
Precedence: bulk

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.