linux-kernel - Re: [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Jan 2020 09:16:54 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Xiaoyao Li <xiaoyao.li@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        x86@...nel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding



> On Jan 30, 2020, at 8:30 AM, Xiaoyao Li <xiaoyao.li@...el.com> wrote:
> 
> On 1/30/2020 11:18 PM, Andy Lutomirski wrote:
>>>> On Jan 30, 2020, at 4:24 AM, Xiaoyao Li <xiaoyao.li@...el.com> wrote:
>>> 
>>> There are two types of #AC can be generated in Intel CPUs:
>>> 1. legacy alignment check #AC;
>>> 2. split lock #AC;
>>> 
>>> Legacy alignment check #AC can be injected to guest if guest has enabled
>>> alignemnet check.
>>> 
>>> When host enables split lock detection, i.e., split_lock_detect!=off,
>>> guest will receive an unexpected #AC when there is a split_lock happens in
>>> guest since KVM doesn't virtualize this feature to guest.
>>> 
>>> Since the old guests lack split_lock #AC handler and may have split lock
>>> buges. To make guest survive from split lock, applying the similar policy
>>> as host's split lock detect configuration:
>>> - host split lock detect is sld_warn:
>>>   warning the split lock happened in guest, and disabling split lock
>>>   detect around VM-enter;
>>> - host split lock detect is sld_fatal:
>>>   forwarding #AC to userspace. (Usually userspace dump the #AC
>>>   exception and kill the guest).
>> A correct userspace implementation should, with a modern guest kernel, forward the exception. Otherwise you’re introducing a DoS into the guest if the guest kernel is fine but guest userspace is buggy.
> 
> To prevent DoS in guest, the better solution is virtualizing and advertising this feature to guest, so guest can explicitly enable it by setting split_lock_detect=fatal, if it's a latest linux guest.
> 
> However, it's another topic, I'll send out the patches later.
> 

Can we get a credible description of how this would work? I suggest:

Intel adds and documents a new CPUID bit or core capability bit that means “split lock detection is forced on”.  If this bit is set, the MSR bit controlling split lock detection is still writable, but split lock detection is on regardless of the value.  Operating systems are expected to set the bit to 1 to indicate to a hypervisor, if present, that they understand that split lock detection is on.

This would be an SDM-only change, but it would also be a commitment to certain behavior for future CPUs that don’t implement split locks.

Can one of you Intel folks ask the architecture team about this?