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

Message-ID: <5833c75e-9f3e-0412-d58c-b6cabdfbdaee@redhat.com>
Date:   Wed, 6 Nov 2019 10:41:17 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org,
        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>
Subject: Re: [PATCH RFC] KVM: x86: tell guests if the exposed SMT topology is
 trustworthy

On 06/11/19 09:32, Peter Zijlstra wrote:
>>> The only way virt topology can make any sense what so ever is if the
>>> vcpus are pinned to physical CPUs.
>>
>> This is a subset of the requirements for "trustworthy" SMT.  You can have:
>>
>> - vCPUs pinned to two threads in the same core and exposed as multiple
>> cores in the guest
> 
> Why the .... would one do anything like that?

If a vCPUs from a different guest could be pinned to a threads in the
same core as this guest (e.g. guests with an odd number of vCPUs), then
why not.  Side-channel wise, you're screwed anyway.

>> - vCPUs from different guests pinned to two threads in the same core
>>
>> and that would be okay as far as KVM_HINTS_REALTIME is concerned, but
>> would still allow exploitation of side-channels, respectively within the
>> VM and between VMs.
> 
> Hardly, RT really rather would not have SMT. SMT is pretty crap for
> determinism.

True, but not a problem as long as the guest knows that - it can ignore
one sibling for each core for RT tasks, and use hyperthreading for
non-RT and housekeeping tasks.

Paolo