lkml.org 
[lkml]   [2022]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86/speculation, KVM: respect user IBPB configuration
On Fri, Apr 15, 2022, Jon Kohler wrote:
>
> > On Apr 15, 2022, at 10:28 AM, Sean Christopherson <seanjc@google.com> wrote:
> > But stepping back, why does KVM do its own IBPB in the first place? The goal is
> > to prevent one vCPU from attacking the next vCPU run on the same pCPU. But unless
> > userspace is running multiple VMs in the same process/mm_struct, switching vCPUs,
> > i.e. switching tasks, will also switch mm_structs and thus do IPBP via cond_mitigation.
>
> Good question, I couldn’t figure out the answer to this by walking the code and looking
> at git history/blame for this area. Are there VMMs that even run multiple VMs within
> the same process? The only case I could think of is a nested situation?

Selftests? :-)

> > If userspace runs multiple VMs in the same process, enables cond_ipbp, _and_ sets
> > TIF_SPEC_IB, then it's being stupid and isn't getting full protection in any case,
> > e.g. if userspace is handling an exit-to-userspace condition for two vCPUs from
> > different VMs, then the kernel could switch between those two vCPUs' tasks without
> > bouncing through KVM and thus without doing KVM's IBPB.
>
> Exactly, so meaning that the only time this would make sense is for some sort of nested
> situation or some other funky VMM tomfoolery, but that nested hypervisor might not be
> KVM, so it's a farce, yea? Meaning that even in that case, there is zero guarantee
> from the host kernel perspective that barriers within that process are being issued on
> switch, which would make this security posture just window dressing?
>
> >
> > I can kinda see doing this for always_ibpb, e.g. if userspace is unaware of spectre
> > and is naively running multiple VMs in the same process.
>
> Agreed. I’ve thought of always_ibpb as "paranoid mode" and if a user signs up for that,
> they rarely care about the fast path / performance implications, even if some of the
> security surface area is just complete window dressing :(
>
> Looking forward, what if we simplified this to have KVM issue barriers IFF always_ibpb?
>
> And drop the cond’s, since the switching mm_structs should take care of that?
>
> The nice part is that then the cond_mitigation() path handles the going to thread
> with flag or going from a thread with flag situation gracefully, and we don’t need to
> try to duplicate that smarts in kvm code or somewhere else.

Unless there's an edge case we're overlooking, that has my vote. And if the
above is captured in a comment, then there shouldn't be any confusion as to why
the kernel/KVM is consuming a flag named "switch_mm" when switching vCPUs, i.e.
when there may or may not have been a change in mm structs.

\
 
 \ /
  Last update: 2022-04-18 18:30    [W:0.278 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site