linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "KarimAllah Ahmed" <karahmed@amazon.de>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andi Kleen" <ak@linux.intel.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Arjan van de Ven" <arjan@linux.intel.com>,
	"Ashok Raj" <ashok.raj@intel.com>,
	"Asit Mallick" <asit.k.mallick@intel.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Janakarajan Natarajan" <Janakarajan.Natarajan@amd.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Jun Nakajima" <jun.nakajima@intel.com>,
	"Laura Abbott" <labbott@redhat.com>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Tim Chen" <tim.c.chen@linux.intel.com>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"KVM list" <kvm@vger.kernel.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"Arjan Van De Ven" <arjan.van.de.ven@intel.com>
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation
Date: Sun, 21 Jan 2018 13:35:59 -0800	[thread overview]
Message-ID: <CA+55aFwOkH8RH12Dzs=hT3e7eS3Ckz9Ed6x_-9a0zs1cw9zbKA@mail.gmail.com> (raw)
In-Reply-To: <1516566497.9814.78.camel@infradead.org>

On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
>> All of this is pure garbage.
>>
>> Is Intel really planning on making this shit architectural? Has
>> anybody talked to them and told them they are f*cking insane?
>>
>> Please, any Intel engineers here - talk to your managers.
>
> If the alternative was a two-decade product recall and giving everyone
> free CPUs, I'm not sure it was entirely insane.

You seem to have bought into the cool-aid. Please add a healthy dose
of critical thinking. Because this isn't the kind of cool-aid that
makes for a fun trip with pretty pictures. This is the kind that melts
your brain.

> Certainly it's a nasty hack, but hey — the world was on fire and in the
> end we didn't have to just turn the datacentres off and go back to goat
> farming, so it's not all bad.

It's not that it's a nasty hack. It's much worse than that.

> As a hack for existing CPUs, it's just about tolerable — as long as it
> can die entirely by the next generation.

That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.

So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.

Honestly, that's completely unacceptable too.

> So the part is I think is odd is the IBRS_ALL feature, where a future
> CPU will advertise "I am able to be not broken" and then you have to
> set the IBRS bit once at boot time to *ask* it not to be broken. That
> part is weird, because it ought to have been treated like the RDCL_NO
> bit — just "you don't have to worry any more, it got better".

It's not "weird" at all. It's very much part of the whole "this is
complete garbage" issue.

The whole IBRS_ALL feature to me very clearly says "Intel is not
serious about this, we'll have a ugly hack that will be so expensive
that we don't want to enable it by default, because that would look
bad in benchmarks".

So instead they try to push the garbage down to us. And they are doing
it entirely wrong, even from a technical standpoint.

I'm sure there is some lawyer there who says "we'll have to go through
motions to protect against a lawsuit". But legal reasons do not make
for good technology, or good patches that I should apply.

> We do need the IBPB feature to complete the protection that retpoline
> gives us — it's that or rebuild all of userspace with retpoline.

BULLSHIT.

Have you _looked_ at the patches you are talking about?  You should
have - several of them bear your name.

The patches do things like add the garbage MSR writes to the kernel
entry/exit points. That's insane. That says "we're trying to protect
the kernel".  We already have retpoline there, with less overhead.

So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out.

If this was about flushing the BTB at actual context switches between
different users, I'd believe you. But that's not at all what the
patches do.

As it is, the patches  are COMPLETE AND UTTER GARBAGE.

They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.

WHAT THE F*CK IS GOING ON?

And that's actually ignoring the much _worse_ issue, namely that the
whole hardware interface is literally mis-designed by morons.

It's mis-designed for two major reasons:

 - the "the interface implies Intel will never fix it" reason.

   See the difference between IBRS_ALL and RDCL_NO. One implies Intel
will fix something. The other does not.

   Do you really think that is acceptable?

 - the "there is no performance indicator".

   The whole point of having cpuid and flags from the
microarchitecture is that we can use those to make decisions.

   But since we already know that the IBRS overhead is <i>huge</i> on
existing hardware, all those hardware capability bits are just
complete and utter garbage. Nobody sane will use them, since the cost
is too damn high. So you end up having to look at "which CPU stepping
is this" anyway.

I think we need something better than this garbage.

                Linus

  reply	other threads:[~2018-01-21 21:35 UTC|newest]

Thread overview: 161+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-20 19:22 [RFC 00/10] Speculation Control feature support KarimAllah Ahmed
2018-01-20 19:22 ` [RFC 01/10] x86/speculation: Add basic support for IBPB KarimAllah Ahmed
2018-01-20 19:22 ` [RFC 02/10] x86/kvm: Add IBPB support KarimAllah Ahmed
2018-01-20 20:18   ` Woodhouse, David
2018-01-22 18:56   ` Jim Mattson
2018-01-22 19:31     ` Jim Mattson
2018-01-20 19:22 ` [RFC 03/10] x86/speculation: Use Indirect Branch Prediction Barrier in context switch KarimAllah Ahmed
2018-01-20 19:22 ` [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process KarimAllah Ahmed
2018-01-20 21:06   ` Woodhouse, David
2018-01-22 18:29     ` Tim Chen
2018-01-21 11:22   ` Peter Zijlstra
2018-01-21 12:04     ` David Woodhouse
2018-01-21 14:07       ` H.J. Lu
2018-01-22 10:19       ` Peter Zijlstra
2018-01-22 10:23         ` David Woodhouse
2018-01-21 16:21     ` Ingo Molnar
2018-01-21 16:25       ` Arjan van de Ven
2018-01-21 22:20       ` Woodhouse, David
2018-01-29  6:35     ` Jon Masters
2018-01-29 14:07       ` Peter Zijlstra
2018-01-20 19:22 ` [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure KarimAllah Ahmed
2018-01-21 14:31   ` Thomas Gleixner
2018-01-21 14:56     ` Borislav Petkov
2018-01-22  9:51       ` Peter Zijlstra
2018-01-22 12:06         ` Borislav Petkov
2018-01-22 13:30           ` Greg Kroah-Hartman
2018-01-22 13:37             ` Woodhouse, David
2018-01-21 15:25     ` David Woodhouse
2018-01-23 20:58     ` David Woodhouse
2018-01-23 22:43       ` Johannes Erdfelt
2018-01-24  8:47       ` Peter Zijlstra
2018-01-24  9:02         ` David Woodhouse
2018-01-24  9:10           ` Greg Kroah-Hartman
2018-01-24 15:09             ` Arjan van de Ven
2018-01-24 15:18               ` David Woodhouse
2018-01-24  9:34           ` Peter Zijlstra
2018-01-24 10:49           ` Henrique de Moraes Holschuh
2018-01-24 12:30             ` David Woodhouse
2018-01-24 12:14         ` David Woodhouse
2018-01-24 12:29           ` Peter Zijlstra
2018-01-24 12:58             ` David Woodhouse
2018-01-29 20:14   ` [RFC,05/10] " Eduardo Habkost
2018-01-29 20:17     ` David Woodhouse
2018-01-29 20:42       ` Eduardo Habkost
2018-01-29 20:44         ` Arjan van de Ven
2018-01-29 21:02           ` David Woodhouse
2018-01-29 21:37             ` Jim Mattson
2018-01-29 21:50               ` Eduardo Habkost
2018-01-29 22:12                 ` Jim Mattson
2018-01-30  1:22                   ` Eduardo Habkost
2018-01-29 22:25                 ` Andi Kleen
2018-01-30  1:37                   ` Eduardo Habkost
2018-01-29 21:37             ` Andi Kleen
2018-01-29 21:44             ` Eduardo Habkost
2018-01-29 22:10               ` Konrad Rzeszutek Wilk
2018-01-30  1:12                 ` Eduardo Habkost
2018-01-30  0:23             ` Linus Torvalds
2018-01-30  1:03               ` Jim Mattson
2018-01-30  3:13                 ` Andi Kleen
2018-01-31 15:03                   ` Paolo Bonzini
2018-01-31 15:07                     ` Dr. David Alan Gilbert
2018-01-30  1:32               ` Arjan van de Ven
2018-01-30  3:32                 ` Linus Torvalds
2018-01-30 12:04                   ` Eduardo Habkost
2018-01-30 13:54                   ` Arjan van de Ven
2018-01-30  8:22               ` David Woodhouse
2018-01-30 11:35               ` David Woodhouse
2018-01-30 11:56               ` Dr. David Alan Gilbert
2018-01-30 12:11               ` Christian Borntraeger
2018-01-30 14:46                 ` Christophe de Dinechin
2018-01-30 14:52                   ` Christian Borntraeger
2018-01-30 14:56                     ` Christophe de Dinechin
2018-01-30 15:33                       ` Christian Borntraeger
2018-01-30 20:46               ` Alan Cox
2018-01-31 10:05                 ` Christophe de Dinechin
2018-01-31 10:15                   ` Thomas Gleixner
2018-01-31 11:04                     ` Dr. David Alan Gilbert
2018-01-31 11:52                       ` Borislav Petkov
2018-01-31 12:30                         ` Dr. David Alan Gilbert
2018-01-31 13:18                           ` Borislav Petkov
2018-01-31 14:04                             ` Dr. David Alan Gilbert
2018-01-31 14:44                               ` Eduardo Habkost
2018-01-31 16:28                                 ` Borislav Petkov
2018-01-31 11:07                     ` Christophe de Dinechin
2018-01-31 15:00                     ` Eduardo Habkost
2018-01-31 15:11                     ` Arjan van de Ven
2018-01-31 10:03   ` [RFC 05/10] " Christophe de Dinechin
2018-01-20 19:22 ` [RFC 06/10] x86/speculation: Add inlines to control Indirect Branch Speculation KarimAllah Ahmed
2018-01-20 19:22 ` [RFC 07/10] x86: Simplify spectre_v2 command line parsing KarimAllah Ahmed
2018-01-20 19:22 ` [RFC 08/10] x86/idle: Control Indirect Branch Speculation in idle KarimAllah Ahmed
2018-01-20 19:23 ` [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation KarimAllah Ahmed
2018-01-21 19:14   ` Andy Lutomirski
2018-01-23 16:12     ` Tom Lendacky
2018-01-23 16:20       ` Woodhouse, David
2018-01-23 22:37         ` Tom Lendacky
2018-01-23 22:49           ` Andi Kleen
2018-01-23 23:14             ` Woodhouse, David
2018-01-23 23:22               ` Andi Kleen
2018-01-24  0:47               ` Tim Chen
2018-01-24  1:00                 ` Andy Lutomirski
2018-01-24  1:22                   ` David Woodhouse
2018-01-24  1:59                   ` Van De Ven, Arjan
2018-01-24  3:25                     ` Andy Lutomirski
2018-01-21 19:34   ` Linus Torvalds
2018-01-21 20:28     ` David Woodhouse
2018-01-21 21:35       ` Linus Torvalds [this message]
2018-01-21 22:00         ` David Woodhouse
2018-01-21 22:27           ` Linus Torvalds
2018-01-22 16:27             ` David Woodhouse
2018-01-23  7:29               ` Ingo Molnar
2018-01-23  7:53                 ` Ingo Molnar
2018-01-23  9:27                   ` Ingo Molnar
2018-01-23  9:37                     ` David Woodhouse
2018-01-23 15:01                     ` Dave Hansen
2018-01-23  9:30                   ` David Woodhouse
2018-01-23 10:15                     ` Ingo Molnar
2018-01-23 10:27                       ` David Woodhouse
2018-01-23 10:44                         ` Ingo Molnar
2018-01-23 10:57                           ` David Woodhouse
2018-01-23 10:23                     ` Ingo Molnar
2018-01-23 10:35                       ` David Woodhouse
2018-02-04 18:43                       ` Thomas Gleixner
2018-02-04 20:22                         ` David Woodhouse
2018-02-06  9:14                         ` David Woodhouse
2018-01-25 16:19                     ` Mason
2018-01-25 17:16                       ` Greg Kroah-Hartman
2018-01-29 11:59                         ` Mason
2018-01-24  0:05                 ` Andi Kleen
2018-01-23 20:16       ` Pavel Machek
2018-01-20 19:23 ` [RFC 10/10] x86/enter: Use IBRS on syscall and interrupts KarimAllah Ahmed
2018-01-21 13:50   ` Konrad Rzeszutek Wilk
2018-01-21 14:40     ` KarimAllah Ahmed
2018-01-21 17:22     ` Dave Hansen
2018-01-21 14:02 ` [RFC 00/10] Speculation Control feature support Konrad Rzeszutek Wilk
2018-01-22 21:27   ` David Woodhouse
2018-01-22 22:15 [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Luke Kenneth Casson Leighton
2018-01-23 11:13 Liran Alon
2018-01-25 22:20 ` Dave Hansen
2018-01-26  2:11 Liran Alon
2018-01-26  2:23 ` Dave Hansen
2018-01-26  9:11   ` David Woodhouse
2018-01-26 17:19     ` Linus Torvalds
2018-01-26 17:27       ` Borislav Petkov
2018-01-26 17:29       ` David Woodhouse
2018-01-26 17:31         ` David Woodhouse
2018-01-26 17:59       ` Andi Kleen
2018-01-26 18:11         ` David Woodhouse
2018-01-26 18:12           ` Arjan van de Ven
2018-01-26 18:26             ` David Woodhouse
2018-01-26 18:28               ` Van De Ven, Arjan
2018-01-26 18:43                 ` David Woodhouse
2018-01-26 18:44                   ` Van De Ven, Arjan
2018-01-26 18:53                     ` David Woodhouse
2018-01-26 19:02         ` Konrad Rzeszutek Wilk
2018-01-26 19:11           ` Hansen, Dave
2018-01-27 13:42             ` Konrad Rzeszutek Wilk
2018-01-27 15:55               ` Dave Hansen
2018-01-26 19:11           ` David Woodhouse
2018-01-26  8:46 ` David Woodhouse
2018-01-26  2:50 Liran Alon
2018-01-26  2:55 ` Van De Ven, Arjan

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='CA+55aFwOkH8RH12Dzs=hT3e7eS3Ckz9Ed6x_-9a0zs1cw9zbKA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=Janakarajan.Natarajan@amd.com \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=arjan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=bp@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=jun.nakajima@intel.com \
    --cc=karahmed@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tim.c.chen@linux.intel.com \
    --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).