[MODERATED] Re: [PATCH v2 3/8] MDSv2 5

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, Dec 10, 2018, 16:03 speck for Andi Kleen <speck@linutronix.de wrote:

>
>
> I don't think it's worth it because going into idle
> isn't really that performance sensitive. Also if the
> side effect is there its overhead really swamps any
> call overhead.
>

It's exactly the  "it's not even there" overhead we should look at.

alternative already handles the noping, so I don't think we would
> need a static branch, unless you want to toggle it at runtime?
>

The whole point is that you're adding a conditional branch and a call for
something that does NOTHING!

>         "verw %[kernelds]" ..  [kernelds] "m" (val)
> >
> > instead, letting gcc do the stack setup part.
>
> It has to be the memory form, only that has the necessary side effect
> in the microcode.
>

That's exactly what the "m" there does.

kernel exit doesn't use the C code, it's custom assembler.


Yes, and that custom assembler has that disgusting call to the SW version
that the code then enables by default.

It's encryption keys etc. too. But yes.
>


I think the encryption key case could easily have a "let's scrub cpu state"
thing.

It already does other strange things, like memset_safe() or whatever it is
that forces a memset even if the compiler decides it's dead.

FWIW from our tests so far the performance loss from the kernel exit
> overhead
> doesn't seem to be that bad.
>

I haven't seen any numbers, and whilei can believe it's true for the verw
case if there is hw acceleration, I doubt the SW case isn't noticeable.

Plus we've already seen that people have been way too eager to apply
patches just because there is alleged security implications, without doing
any kind of risk vs cost analysis.

      Linus

>