Re: [PATCH v3] x86/speculation, KVM: only IBPB for switch_mm_always_ibpb on vCPU load

[Borislav Petkov <bp@alien8.de>]

On Fri, Apr 29, 2022 at 08:29:30PM +0000, Sean Christopherson wrote:
> That's why there's a bunch of hand-waving.

Well, I'm still not sure what this patch is trying to fix but both your
latest replies do sound clearer...

> Can you clarify what "this" is?  Does "this" mean "this patch", or does it mean

This patch.

> "this IBPB when switching vCPUs"?  Because if it means the latter, then I think
> you're in violent agreement; the IBPB when switching vCPUs is pointless and
> unnecessary.

Ok, let's concentrate on the bug first - whether a second IBPB - so to
speak - is needed. Doing some git archeology points to:

  15d45071523d ("KVM/x86: Add IBPB support")

which - and I'm surprised - goes to great lengths to explain what
those IBPB calls in KVM protect against. From that commit message, for
example:

"    * Mitigate attacks from guest/ring3->host/ring3.
      These would require a IBPB during context switch in host, or after
      VMEXIT."

so with my very limited virt understanding, when you vmexit, you don't
do switch_mm(), right?

If so, you need to do a barrier. Regardless of conditional IBPB or not
as you want to protect the host from a malicious guest.

In general, the whole mitigation strategies are enumerated in

Documentation/admin-guide/hw-vuln/spectre.rst

There's also a "3. VM mitigation" section.

And so on...

Bottomline is this: at the time, we went to great lengths to document
what the attacks are and how we are protecting against them.

So now, if you want to change all that, I'd like to see

- the attack scenario is this

- we don't think it is relevant because...

- therefore, we don't need to protect against it anymore

and all that should be properly documented.

Otherwise, there's no surviving this mess.

Thx!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette