linux-kernel - Re: [PATCH 01/18] KVM: x86: hyper-v: Introduce XMM output support

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]

Message-ID: <D381CRQ2XJL9.1NBVMKT4SR51P@amazon.com>
Date: Mon, 5 Aug 2024 14:08:46 +0000
From: Nicolas Saenz Julienne <nsaenz@...zon.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>, <linux-kernel@...r.kernel.org>,
	<kvm@...r.kernel.org>
CC: <pbonzini@...hat.com>, <seanjc@...gle.com>, <linux-doc@...r.kernel.org>,
	<linux-hyperv@...r.kernel.org>, <linux-arch@...r.kernel.org>,
	<linux-trace-kernel@...r.kernel.org>, <graf@...zon.de>,
	<dwmw2@...radead.org>, <pdurrant@...zon.com>, <mlevitsk@...hat.com>,
	<jgowans@...zon.com>, <corbet@....net>, <decui@...rosoft.com>,
	<tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>, <x86@...nel.org>, <amoorthy@...gle.com>
Subject: Re: [PATCH 01/18] KVM: x86: hyper-v: Introduce XMM output support

On Mon Jul 29, 2024 at 1:53 PM UTC, Vitaly Kuznetsov wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> Nicolas Saenz Julienne <nsaenz@...zon.com> writes:
>
> > Hi Vitaly,
> > Thanks for having a look at this.
> >
> > On Mon Jul 8, 2024 at 2:59 PM UTC, Vitaly Kuznetsov wrote:
> >> Nicolas Saenz Julienne <nsaenz@...zon.com> writes:
> >>
> >> > Prepare infrastructure to be able to return data through the XMM
> >> > registers when Hyper-V hypercalls are issues in fast mode. The XMM
> >> > registers are exposed to user-space through KVM_EXIT_HYPERV_HCALL and
> >> > restored on successful hypercall completion.
> >> >
> >> > Signed-off-by: Nicolas Saenz Julienne <nsaenz@...zon.com>
> >> >
> >> > ---
> >> >
> >> > There was some discussion in the RFC about whether growing 'struct
> >> > kvm_hyperv_exit' is ABI breakage. IMO it isn't:
> >> > - There is padding in 'struct kvm_run' that ensures that a bigger
> >> >   'struct kvm_hyperv_exit' doesn't alter the offsets within that struct.
> >> > - Adding a new field at the bottom of the 'hcall' field within the
> >> >   'struct kvm_hyperv_exit' should be fine as well, as it doesn't alter
> >> >   the offsets within that struct either.
> >> > - Ultimately, previous updates to 'struct kvm_hyperv_exit's hint that
> >> >   its size isn't part of the uABI. It already grew when syndbg was
> >> >   introduced.
> >>
> >> Yes but SYNDBG exit comes with KVM_EXIT_HYPERV_SYNDBG. While I don't see
> >> any immediate issues with the current approach, we may want to introduce
> >> something like KVM_EXIT_HYPERV_HCALL_XMM: the userspace must be prepared
> >> to handle this new information anyway and it is better to make
> >> unprepared userspace fail with 'unknown exit' then to mishandle a
> >> hypercall by ignoring XMM portion of the data.
> >
> > OK, I'll go that way. Just wanted to get a better understanding of why
> > you felt it was necessary.
> >
>
> (sorry for delayed reply, I was on vacation)
>
> I don't think it's an absolute must but it appears as a cleaner approach
> to me.
>
> Imagine there's some userspace which handles KVM_EXIT_HYPERV_HCALL today
> and we want to add XMM handling there. How would we know if xmm portion
> of the data is actually filled by KVM or not? With your patch, we can of
> course check for HV_X64_HYPERCALL_XMM_OUTPUT_AVAILABLE in
> KVM_GET_SUPPORTED_HV_CPUID but this is not really straightforward, is
> it? Checking the size is not good either. E.g. think about downstream
> versions of KVM which may or may not have certain backports. In case we
> (theoretically) do several additions to 'struct kvm_hyperv_exit', it
> will quickly become a nightmare.
>
> On the contrary, KVM_EXIT_HYPERV_HCALL_XMM (or just
> KVM_EXIT_HYPERV_HCALL2) approach looks cleaner: once userspace sees it,
> it knows that 'xmm' portion of the data can be relied upon.

Makes sense, thanks for the explanation.

Nicolas