linux-kernel - Re: [PATCH 2/4] x86/vmware: Add a header file for hypercall definitions

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, 19 Aug 2019 09:49:11 +0200
From:   Thomas Hellström (VMware) 
        <thomas_os@...pmail.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, pv-drivers@...are.com,
        Thomas Hellstrom <thellstrom@...are.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Doug Covelli <dcovelli@...are.com>
Subject: Re: [PATCH 2/4] x86/vmware: Add a header file for hypercall
 definitions

On 8/19/19 8:25 AM, Borislav Petkov wrote:
> On Mon, Aug 19, 2019 at 12:28:05AM +0200, Thomas Hellström (VMware) wrote:
>> Unfortunately we can't use it, because it's unconditionally set on AMD even
>> if the VMware hypervisor
>> doesn't support it (by version or by configuration).
> AMD sets it because they don't support VMCALL. Nothing stops us from
> making that conditional depending on what the hypervisor can/supports.
> I'm thinking it would be even cleaner if we use those two flags:
>
> X86_FEATURE_VMMCALL
> X86_FEATURE_VMCALL
>
> to denote hw support for either one or the other instruction and switch
> accordingly. Just like KVM does.
>
> In your case, the HV would set the preferred flag in
> arch/x86/kernel/cpu/vmware.c - just like the others do in their
> respective CPU init files - and the alternatives code would switch to it
> when it runs.
>
> Or is there more? :)

Yes, unfortunately. I agree this is is the cleanest solution and my 
first choice. It would work for VMware, but AFAICT it might break setups 
of other hypervisors running at least the vmmouse driver. Quick googling 
tells me there are likely QEMU/KVM setups that do this. My thinking is 
they would have to set X86_FEATURE_VMMCALL on AMD to get the 
kvm_hypercall right, but that would mean the vmmouse hypercall also uses 
vmmcall, which they probably haven't implemented (yet). So the safe way 
would be to use at least XF86_FEATURE_VMW_VMMCALL + XF86_FEATURE_VMCALL 
until that has happened.

/Thomas


>
> Thx.
>