linux-kernel - Re: [PATCH v2] KVM: X86: #GP when guest attempts to write MCi

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] [day] [month] [year] [list]

Date:   Thu, 2 Nov 2017 11:57:07 -0700
From:   Jim Mattson <jmattson@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Wanpeng Li <kernellwp@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kvm list <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH v2] KVM: X86: #GP when guest attempts to write MCi_STATUS
 register w/o 0

You're right, of course. My only remaining concern is that no real
hardware constrains these MSRs to three values as kvm does. On Intel
P6, only two values are allowed. On AMD CPUs, any value is allowed.

On Thu, Nov 2, 2017 at 10:35 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> On 19/10/2017 20:09, Jim Mattson wrote:
>> "(offset & 0x3) == 1" seems like an obfuscated way of writing the
>> predicate, is_mci_status_msr(msr). But other than that, this change
>> looks fine to me.
>>
>> I'm a little more concerned about the code above. At the very least,
>> it needs to let the host set an arbitrary value for save/restore to
>> work.
>
> Why?  The guest cannot have written anything but the three allowed
> values, userspace cannot write anything else either outside save/restore
> without KVM_SET_MSR failing, and KVM itself (specifically
> kvm_vcpu_ioctl_x86_setup_mce) only ever initializes IA32_MCi_CTL to all
> ones.  So save will only ever find those three values, and restore's
> KVM_SET_MSR restore should never fail either.
>
> Thanks,
>
> Paolo
>
>> Reviewed-by: Jim Mattson <jmattson@...gle.com>
>