linux-kernel - Re: [PATCH RFC] KVM: nSVM: Fix L1 state corruption upon return from SMM

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:   Thu, 24 Jun 2021 09:41:57 +0200
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Maxim Levitsky <mlevitsk@...hat.com>
Cc:     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, kvm@...r.kernel.org
Subject: Re: [PATCH RFC] KVM: nSVM: Fix L1 state corruption upon return from
 SMM

Paolo Bonzini <pbonzini@...hat.com> writes:

> On 23/06/21 18:21, Sean Christopherson wrote:
>> On Wed, Jun 23, 2021, Sean Christopherson wrote:
>>> And I believe this hackery is necessary only because nested_svm_vmexit() isn't
>>> following the architcture in the first place.  I.e. using vmcb01 to restore
>>> host state is flat out wrong.
>> 
>> Ah, that's not true, using vmcb01 is allowed by "may store some or all host state
>> in hidden on-chip memory".
>
> And also, "Different implementations may choose to save the hidden parts 
> of the host’s segment registers as well as the selectors".
>
>>  From a performance perspective, I do like the SMI/RSM shenanigans.  I'm not
>> totally opposed to the trickery since I think it will break a guest if and only
>> if the L1 guest is also violating the APM.  And we're not fudging the spec thaat
>> much :-)
>
> Yeah, that was my reasoning as well.  Any reference to "hidden on-chip 
> memory", plus the forbidding modifications of the host save area, sort 
> of implies that the processor can actually flush that hidden on-chip 
> memory for whatever reason (such as on some sleep states?!?).

Ok, so it seems nobody feel strongly against the idea I've implemented
in the RFC. We could've avoided saving L1 host state upon L2 enter in
vmcb01 altogether, true, but we would still need some sort of a cache
emulating "hidden on-chip memory" for performance reasons. Resurrecting
'hsave'/ allocating 'special' vmcb01_smm/... and modifying nested state
seems to be unneeded, the L2->SMM case should be rare indeed.

I'll add a testcase to smm selftest and submit v1 then, thanks!

-- 
Vitaly