Message-ID: <c5809098-9066-d90d-1bcc-108a11525cac@intel.com>
Date:   Wed, 1 Feb 2023 10:09:16 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Jann Horn <jannh@...gle.com>, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-hardening@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Roxana Bradescu <roxabee@...omium.org>,
        Adam Langley <agl@...gle.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        "Jason A . Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH] x86: enable Data Operand Independent Timing Mode

On 1/31/23 22:54, Eric Biggers wrote:
> On Tue, Jan 31, 2023 at 02:48:05PM -0800, Dave Hansen wrote:
>> We've been talking about this inside Intel.  Suffice to say that DOITM
>> was not designed to be turned on all the time.  If software turns it on
>> all the time, it won't accomplish what it was designed to do.
> 
> Why wouldn't it accomplish what it is designed to do?  Does it not actually
> work?

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.

>> The _most_ likely thing that's going to happen is that DOITM gets
>> redefined to be much more limited in scope.  The current DOITM
>> architecture is very broad, but the implementations have much more
>> limited effects.  This means that the architecture can probably be
>> constrained and still match the hardware that's out there today.  That's
>> pure speculation (ha!) on my part.
>>
>> I think we should hold off on merging any DOITM patches until the dust
>> settles.  As far as I know, there is no pressing practical reason to
>> apply something urgently.
>>
>> Any objections?
> 
> Does this mean that Intel will be restoring the data operand independent timing
> guarantee of some instructions that have had it removed?  If so, which
> instructions will still be left?

Speaking for myself and *not* the official Intel plan here.  Yes, I
think the pre-DOITM behavior can and will be restored for basically the
entire list[1] (ignoring MCDT of course).

> Also, given that the DOITM flag can only be set and cleared by the
> kernel, and assuming that Linux won't support DOITM in any way yet
> (as you're recommending), what should the developers of userspace
> cryptographic libraries do? Does Intel have a list of which
> instructions *already* have started having data operand dependent
> timing on released CPUs, so that the existing security impact can be
> assessed and so that developers can avoid using those instructions?
Good questions.  I want to make sure what I'm saying here is accurate,
and I don't have good answers to those right now.  We're working on it,
and should have something useful to say in the next couple of days.

1.
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/resources/data-operand-independent-timing-instructions.html

Powered by blists - more mailing lists