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: <e4ba5286-f683-5876-1cd7-7fc83bc1638e@redhat.com>
Date:   Wed, 23 Jun 2021 14:00:28 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Maxim Levitsky <mlevitsk@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Cathy Avery <cavery@...hat.com>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] KVM: nSVM: Fix L1 state corruption upon return from
 SMM

On 23/06/21 13:39, Maxim Levitsky wrote:
> On Wed, 2021-06-23 at 11:39 +0200, Paolo Bonzini wrote:
>> On 23/06/21 09:44, Vitaly Kuznetsov wrote:
>>> - RFC: I'm not 100% sure my 'smart' idea to use currently-unused HSAVE area
>>> is that smart. Also, we don't even seem to check that L1 set it up upon
>>> nested VMRUN so hypervisors which don't do that may remain broken. A very
>>> much needed selftest is also missing.
>>
>> It's certainly a bit weird, but I guess it counts as smart too.  It
>> needs a few more comments, but I think it's a good solution.
>>
>> One could delay the backwards memcpy until vmexit time, but that would
>> require a new flag so it's not worth it for what is a pretty rare and
>> already expensive case.
> 
> I wonder what would happen if SMM entry is triggered by L1 (say with ICR),
> on a VCPU which is in L2. Such exit should go straight to L1 SMM mode.

Yes, it does, but it still records the L2 state in the guest's SMM state 
save area.  Everything works right as long as the guest stays in L2 (the 
vmcb12 control save area is still there in svm->nested and is 
saved/restored by KVM_GET/SET_NESTED_STATE), the problem that Vitaly 
found is the destruction of the saved L1 host state.

Paolo

> I will very very soon, maybe even today start testing SMM with my migration
> tests and such. I hope I will find more bugs in this area.
> 
> Thanks for fixing this issue!
> 
> Best regards,
> 	Maxim Levitsky
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ