[lkml]   [2018]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation
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.

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.

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

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".

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

We'll also want to expose IBRS to VM guests, since Windows uses it.

I think we could probably live without the IBRS frobbing in our own
syscall/interrupt paths, as long as we're prepared to live with the
very hypothetical holes that still exist on Skylake. Because I like
IBRS more... no, let me rephrase... I hate IBRS less than I hate the
'deepstack' and other stuff that was being proposed to make Skylake
almost safe with retpoline.[unhandled content-type:application/x-pkcs7-signature]
 \ /
  Last update: 2018-01-21 21:29    [W:0.014 / U:19.500 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site