linux-hardening - 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]

Date:   Wed, 25 Jan 2023 08:45:56 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Eric Biggers <ebiggers@...nel.org>,
        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>,
        "Jason A . Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH] x86: enable Data Operand Independent Timing Mode

On 1/25/23 08:22, Ard Biesheuvel wrote:
...
> All the nospec stuff we added for Spectre v1 serves the same purpose,
> essentially, although the timing variances due to cache misses are
> likely easier to measure. IOW, some of the kernel is now written that
> way in fact, although the author of that doc may have had something
> else in mind.
> 
> So IMHO, the scope is really not as narrow as you think.

I've spoken with the folks who wrote that doc.  They've told me
repeatedly that the scope is super narrow.  Seriously, look at just
*one* thing in the other Intel doc about mitigating timing side-channels[1]:

	be wary of code generated from high-level language source code
	that appears to adhere to all of these recommendations.

The kernel has a fair amount of code written in high-level languages.

The authors of the DOIT doc truly intend the real-world benefits of
DOITM to be exceedingly narrow.  I think it would be fair to say that
they think:

	DOITM is basically useless for most code written in C, including
	basically the entire kernel.

I'll go forward this on to them and make sure I'm not overstating this
_too_ much.

>> That's _meant_ to be really scary and keep folks from turning this on by
>> default, aka. what this patch does.  Your new CPU will be really slow if
>> you turn this on!  Boo!
> 
> What is the penalty for switching it on and off? On arm64, it is now
> on by default in the kernel, and off by default in user space, and
> user space can opt into it using an unprivileged instruction.

Right now, DOITM is controlled by a bit in an MSR and it applies
everywhere.  It is (thankfully) one of the cheap MSRs and is not
architecturally serializing.

That's still not ideal and there is a desire to expose the bit to
userspace *somehow* to make it much, much cheaper to toggle.  But, it'll
still be an extra bit that needs to get managed and context switched.

When I looked, the arm64 bit seemed to be in some flags register that
got naturally saved and restored already on user<->kernel transitions.
Was I reading it right?  It seemed like a really nice, simple mechanism
to me.

1.
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/mitigate-timing-side-channel-crypto-implementation.html