linux-kernel - Re: [PATCH RFC 11/39] KVM: x86/xen: evtchn signaling via eventfd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 Nov 2020 18:01:25 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Joao Martins <joao.m.martins@...cle.com>,
        Ankur Arora <ankur.a.arora@...cle.com>
Cc:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 11/39] KVM: x86/xen: evtchn signaling via eventfd

On Mon, 2020-11-30 at 17:15 +0000, Joao Martins wrote:
> On 11/30/20 4:48 PM, David Woodhouse wrote:
> > On Mon, 2020-11-30 at 15:08 +0000, Joao Martins wrote:
> > > On 11/30/20 12:55 PM, David Woodhouse wrote:
> > > > On Mon, 2020-11-30 at 12:17 +0000, Joao Martins wrote:
> > > > > On 11/30/20 9:41 AM, David Woodhouse wrote:
> > > > > > On Wed, 2019-02-20 at 20:15 +0000, Joao Martins wrote:
> > > > > 
> > > > > One thing I didn't quite do at the time, is the whitelisting of unregistered
> > > > > ports to userspace.

...

> But felt it was still worth having this discussion ... should this be
> considered or discarded. I suppose we stick with the later for now.

Ack. Duly discarded :)

> > > > > Perhaps eventfd could be a way to express this? Like if you register
> > > > > without an eventfd it's offloaded, otherwise it's assigned to userspace,
> > > > > or if neither it's then returned an error without bothering the VMM.
> > > > 
> > > > I much prefer the simple model where the *only* event channels that the
> > > > kernel knows about are the ones it's expected to handle.
> > > > 
> > > > For any others, the bypass doesn't kick in, and userspace gets the
> > > > KVM_EXIT_HYPERCALL exit.
> > > > 
> > > 
> > > /me nods
> > > 
> > > I should comment on your other patch but: if we're going to make it generic for
> > > the userspace hypercall handling, might as well move hyper-v there too. In this series,
> > > I added KVM_EXIT_XEN, much like it exists KVM_EXIT_HYPERV -- but with a generic version
> > > I wonder if a capability could gate KVM_EXIT_HYPERCALL to handle both guest types, while
> > > disabling KVM_EXIT_HYPERV. But this is probably subject of its own separate patch :)
> > 
> > There's a limit to how much consolidation we can do because the ABI is
> > different; the args are in different registers.
> > 
> 
> Yes. It would be optionally enabled of course and VMM would have to adjust to the new ABI
> -- surely wouldn't want to break current users of KVM_EXIT_HYPERV.

True, but that means we'd have to keep KVM_EXIT_HYPERV around anyway,
and can't actually *remove* it. The "consolidation" gives us more
complexity, not less.

> > I do suspect Hyper-V should have marshalled its arguments into the
> > existing kvm_run->arch.hypercall and used KVM_EXIT_HYPERCALL but I
> > don't think it makes sense to change it now since it's a user-facing
> > ABI. I don't want to follow its lead by inventing *another* gratuitous
> > exit type for Xen though.
> > 
> 
> I definitely like the KVM_EXIT_HYPERCALL better than a KVM_EXIT_XEN userspace
> exit type ;)
> 
> But I guess you still need to co-relate a type of hypercall (Xen guest cap enabled?) to
> tell it's Xen or KVM to specially enlighten certain opcodes (EVTCHNOP_send).

Sure, but if the VMM doesn't know what kind of guest it's hosting, we
have bigger problems... :)


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5174 bytes)