linux-kernel - Re: [PATCH v4 2/2] KVM: SVM: Add support for Virtual SPEC

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]

Message-ID: <CALMp9eT1_G1yp30K=DqEUsV=yK_w9KoU_ANnSPq4ueqzBTkLZw@mail.gmail.com>
Date:   Mon, 13 Jun 2022 13:28:13 -0700
From:   Jim Mattson <jmattson@...gle.com>
To:     Tom Lendacky <thomas.lendacky@....com>
Cc:     Babu Moger <babu.moger@....com>, pbonzini@...hat.com,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        fenghua.yu@...el.com, tony.luck@...el.com, wanpengli@...cent.com,
        kvm@...r.kernel.org, peterz@...radead.org, seanjc@...gle.com,
        joro@...tes.org, x86@...nel.org, kyung.min.park@...el.com,
        linux-kernel@...r.kernel.org, krish.sadhukhan@...cle.com,
        hpa@...or.com, mgross@...ux.intel.com, vkuznets@...hat.com,
        kim.phillips@....com, wei.huang2@....com
Subject: Re: [PATCH v4 2/2] KVM: SVM: Add support for Virtual SPEC_CTRL

On Mon, Jun 13, 2022 at 1:16 PM Tom Lendacky <thomas.lendacky@....com> wrote:

> Ah, yes, I get it now. I wasn't picking up on the aspect of running older
> KVM versions on the newer hardware, sorry.
>
> I understand what you're driving at, now. We do tell the hardware teams
> that add this type of feature that we need a VMCB enable bit, e.g. make it
> an opt in feature. I'll be sure to communicate that to them again so that
> this type of issue can be avoided in the future.

Thank you so much. Might I also ask that new features get promptly
documented in the APM?

It took us an incredibly long time to figure out why just one vCPU
thread would run slow on every GCE AMD instance. It wasn't always the
same thread, but the slow vCPU thread would still be slow even after
live migration. On a guest reboot, the slowness might migrate to a
different vCPU thread. How bizarre, right?

It turns out that, on UEFI-enabled images, one vCPU makes an EFI
firmware call, which sets IBRS. You can't see that IBRS is on from
within the guest, but it is, because of the sticky first non-zero
write behavior induced by virtual SPEC_CTRL.