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:   Fri, 23 Apr 2021 11:24:04 +0200
From:   Alexander Graf <graf@...zon.com>
To:     Siddharth Chandrasekaran <sidcha@...zon.de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        "Vitaly Kuznetsov" <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        "Jim Mattson" <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "Borislav Petkov" <bp@...en8.de>, <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>
CC:     Evgeny Iakovlev <eyakovl@...zon.de>, Liran Alon <liran@...zon.com>,
        Ioannis Aslanidis <iaslan@...zon.de>, <kvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: hyper-v: Add new exit reason HYPERV_OVERLAY



On 23.04.21 11:03, Siddharth Chandrasekaran wrote:
> Hypercall code page is specified in the Hyper-V TLFS to be an overlay
> page, ie., guest chooses a GPA and the host _places_ a page at that
> location, making it visible to the guest and the existing page becomes
> inaccessible. Similarly when disabled, the host should _remove_ the
> overlay and the old page should become visible to the guest.
> 
> Currently KVM directly patches the hypercall code into the guest chosen
> GPA. Since the guest seldom moves the hypercall code page around, it
> doesn't see any problems even though we are corrupting the exiting data
> in that GPA.
> 
> VSM API introduces more complex overlay workflows during VTL switches
> where the guest starts to expect that the existing page is intact. This
> means we need a more generic approach to handling overlay pages: add a
> new exit reason KVM_EXIT_HYPERV_OVERLAY that exits to userspace with the
> expectation that a page gets overlaid there.

I can see how that may get interesting for other overlay pages later, 
but this one in particular is just an MSR write, no? Is there any reason 
we can't just use the user space MSR handling logic instead?

What's missing then is a way to pull the hcall page contents from KVM. 
But even there I'm not convinced that KVM should be the reference point 
for its contents. Isn't user space in an as good position to assemble it?

> 
> In the interest of maintaing userspace exposed behaviour, add a new KVM
> capability to allow the VMMs to enable this if they can handle the
> hypercall page in userspace.
> 
> Signed-off-by: Siddharth Chandrasekaran <sidcha@...zon.de>
> 
> CR: https://code.amazon.com/reviews/CR-49011379

Please remove this line from upstream submissions :).

> ---
>   arch/x86/include/asm/kvm_host.h |  4 ++++
>   arch/x86/kvm/hyperv.c           | 25 ++++++++++++++++++++++---
>   arch/x86/kvm/x86.c              |  5 +++++
>   include/uapi/linux/kvm.h        | 10 ++++++++++

You're modifying / adding a user space API. Please make sure to update 
the documentation in Documentation/virt/kvm/api.rst when you do that.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ