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:09:30 -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: <Yw0O6pQ7oKHGmQ0O@zx2c4.com>
References: <YwgCrqutxmX0W72r@gmail.com>
 <Ywzr2d52ixYXUDWR@zx2c4.com>
 <Yw0Ah5m/2HDDvCjS@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Yw0Ah5m/2HDDvCjS@gmail.com>
Precedence: bulk

On Mon, Aug 29, 2022 at 06:08:07PM +0000, Eric Biggers wrote:
> I'd much prefer it being set unconditionally by default as well, as making
> everyone (both kernel and userspace) turn it on and off constantly would be a
> nightmare.
> 
> Note that Intel's documentation says that CPUs before Ice Lake behave as if
> DOITM is always set:
> 
>     "For Intel® Core™ family processors based on microarchitectures before Ice
>     Lake and Intel Atom® family processors based on microarchitectures before
>     Gracemont that do not enumerate IA32_UARCH_MISC_CTL, developers may assume
>     that the instructions listed here operate as if DOITM is enabled."
> 
> (It's a bit ambiguous, as it leaves the door open to IA32_UARCH_MISC_CTL being
> retroactively added to old CPUs.  But I assume that hasn't actually happened.)
> 
> So I think the logical approach is to unconditionally set DOITM by default, to
> fix this CPU bug in Ice Lake and later and just bring things back to the way
> they were in CPUs before Ice Lake.  With that as a baseline, we can then discuss
> whether it's useful to provide ways to re-enable this CPU bug / "feature", for
> people who want to get the performance boost (if one actually exists) of data
> dependent timing after carefully assessing the risks.
> 
> The other way around, of making everything insecure by default, seems like a
> really bad idea.

Right. It's actually kind of surprising that Intel didn't already do
this by default. Sure, maybe the Intel manual never explicitly
guaranteed constant time, but a heck of a lot of code relies on that
being the case.

Jason