linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-crypto@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Roxana Bradescu <roxabee@chromium.org>,
	Adam Langley <agl@google.com>,
	"Jason A . Donenfeld" <Jason@zx2c4.com>
Subject: Re: [PATCH] x86: enable Data Operand Independent Timing Mode
Date: Wed, 25 Jan 2023 08:45:56 -0800	[thread overview]
Message-ID: <1000ec59-c8b7-e546-5baa-bdd0e878bf76@intel.com> (raw)
In-Reply-To: <CAMj1kXEZi1ewVdqXHTi7kWX9aT+j1=rFOVE55LdJYb9LkV9Dkw@mail.gmail.com>

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

  reply	other threads:[~2023-01-25 16:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25  1:28 [PATCH] x86: enable Data Operand Independent Timing Mode Eric Biggers
2023-01-25  3:07 ` Bagas Sanjaya
2023-01-25 15:29 ` Dave Hansen
2023-01-25 16:15   ` Dave Hansen
2023-01-25 16:22   ` Ard Biesheuvel
2023-01-25 16:45     ` Dave Hansen [this message]
2023-01-26 10:20       ` Ard Biesheuvel
2023-01-26 13:52   ` Jann Horn
2023-01-26 16:40     ` Dave Hansen
2023-01-26 17:52       ` Jann Horn
2023-01-26 19:12         ` Dave Hansen
2023-01-26 22:37           ` Eric Biggers
2023-01-26 23:58             ` Dave Hansen
2023-01-31 22:48               ` Dave Hansen
2023-02-01  6:54                 ` Eric Biggers
2023-02-01 18:09                   ` Dave Hansen
2023-02-01 22:33                     ` Josh Triplett
2023-02-03 16:25                     ` Dave Hansen
2023-02-03 18:25 ` Dave Hansen
2023-03-03  3:32   ` Roxana Bradescu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1000ec59-c8b7-e546-5baa-bdd0e878bf76@intel.com \
    --to=dave.hansen@intel.com \
    --cc=Jason@zx2c4.com \
    --cc=agl@google.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=ebiggers@kernel.org \
    --cc=hpa@zytor.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roxabee@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).