linux-kernel - Re: [PATCH RFC] KVM: x86: tell guests if the exposed SMT topology is trustworthy

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:   Mon, 9 Dec 2019 10:15:12 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Ankur Arora <ankur.a.arora@...cle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Jim Mattson <jmattson@...gle.com>,
        Liran Alon <liran.alon@...cle.com>,
        linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        kvm@...r.kernel.org
Subject: Re: [PATCH RFC] KVM: x86: tell guests if the exposed SMT topology is
 trustworthy

On 06/12/19 21:31, Ankur Arora wrote:
>> If we, however, discuss other hints such 'pre-ACK' mechanism may make
>> sense, however, I'd make it an option to a 'challenge/response'
>> protocol: if host wants to change a hint it notifies the guest and waits
>> for an ACK from it (e.g. a pair of MSRs + an interrupt). I, however,
>
> My main reason for this 'pre-ACK' approach is some discomfort with
> changing the CPUID edx from under the guest.

Changing the CPUID is fine, if we document which CPUID can change.
There are CPUID leaves that change at runtime, for example in leaf 0Dh
(though in that case it's based on XCR0 and not on external circumstances).

> As we've discussed offlist, the particular hint I'm interested in is
> KVM_HINT_REALTIME. That's not a particularly good candidate though
> because there's no correctness problem if the host does switch it
> off suddenly. 

Or perhaps it's a good candidate, exactly because there's no correctness
problem.  For SMT topology, there are security issues if the host
doesn't respect it anymore, so making it changeable is of limited utility.

Paolo