linux-kernel - Re: [PATCH] x86: enable Data Operand Independent Timing Mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y9rosOyM+BgMqOzO@localhost>
Date:   Wed, 1 Feb 2023 14:33:20 -0800
From:   Josh Triplett <josh@...htriplett.org>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Eric Biggers <ebiggers@...nel.org>, 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 Wed, Feb 01, 2023 at 10:09:16AM -0800, Dave Hansen wrote:
> 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.

It seems like it still potentially accomplishes its intended purpose
even if it's opt-in. A prctl to turn it on for a particular process, or
a particular process and its children, could work if that process knows
it wants all the performance it can get and won't be handling data for
which privilege boundaries matter. If this actually has the potential
for substantial optimizations that would be worth it.

But yeah, opt-out seems like a non-starter, since it'd require fixing
all the cryptographic code in the world to request DOITM=1.