linux-kernel - Re: [RFC 29/33] KVM: VMX: Save instruction length on EPT violation

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:   Wed, 8 Nov 2023 18:27:34 +0100
From:   Alexander Graf <graf@...zon.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        Nicolas Saenz Julienne <nsaenz@...zon.com>
CC:     <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-hyperv@...r.kernel.org>, <pbonzini@...hat.com>,
        <vkuznets@...hat.com>, <anelkz@...zon.com>, <dwmw@...zon.co.uk>,
        <jgowans@...zon.com>, <corbert@....net>, <kys@...rosoft.com>,
        <haiyangz@...rosoft.com>, <decui@...rosoft.com>, <x86@...nel.org>,
        <linux-doc@...r.kernel.org>
Subject: Re: [RFC 29/33] KVM: VMX: Save instruction length on EPT violation


On 08.11.23 18:20, Sean Christopherson wrote:
> On Wed, Nov 08, 2023, Nicolas Saenz Julienne wrote:
>> Save the length of the instruction that triggered an EPT violation in
>> struct kvm_vcpu_arch. This will be used to populate Hyper-V VSM memory
>> intercept messages.
> This is silly and unnecessarily obfuscates *why* (as my response regarding SVM
> shows), i.e. that this is "needed" becuase the value is consumed by a *different*
> vCPU, not because of performance concerns.
>
> It's also broken, AFAICT nothing prevents the intercepted vCPU from hitting a
> different EPT violation before the target vCPU consumes exit_instruction_len.
>
> Holy cow.  All of deliver_gpa_intercept() is wildly unsafe.  Aside from race
> conditions, which in and of themselves are a non-starter, nothing guarantees that
> the intercepted vCPU actually cached all of the information that is held in its VMCS.
>
> The sane way to do this is to snapshot *all* information on the intercepted vCPU,
> and then hand that off as a payload to the target vCPU.  That is, assuming the
> cross-vCPU stuff is actually necessary.  At a glance, I don't see anything that
> explains *why*.


Yup, I believe you repeated the comment I had on the function - and 
Nicolas already agreed :). This should go through user space which 
automatically means you need to bubble up all necessary trap data to 
user space on the faulting vCPU and then inject the full set of data 
into the receiving one.

My point with the comment on this patch was "Don't break AMD (or ancient 
VMX without instruction length decoding [Does that exist? I know SVM has 
old CPUs that don't do it]) please".


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