linux-kernel - Re: [PATCH 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 for Android: free password hash cracker in your pocket

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

Message-Id: <20201210213148.18996-1-babu.moger@amd.com>
Date:   Thu, 10 Dec 2020 15:31:48 -0600
From:   Babu Moger <babu.moger@....com>
To:     seanjc@...gle.com
Cc:     babu.moger@....com, bp@...en8.de, fenghua.yu@...el.com,
        hpa@...or.com, jmattson@...gle.com, joro@...tes.org,
        kim.phillips@....com, krish.sadhukhan@...cle.com,
        kvm@...r.kernel.org, kyung.min.park@...el.com,
        linux-kernel@...r.kernel.org, mgross@...ux.intel.com,
        mingo@...hat.com, pbonzini@...hat.com, peterz@...radead.org,
        tglx@...utronix.de, thomas.lendacky@....com, tony.luck@...el.com,
        vkuznets@...hat.com, wanpengli@...cent.com, wei.huang2@....com,
        x86@...nel.org
Subject: Re: [PATCH 2/2] KVM: SVM: Add support for Virtual SPEC_CTRL

Sean, Your response did not land in my mailbox for some reason.
 Replying using In-reply-to option.

>Hrm, is MSR_AMD64_VIRT_SPEC_CTRL only for SSBD?  Should that MSR be renamed to
>avoid confusion with the new form of VIRT_SPEC_CTRL?

We can rename it to MSR_AMD64_VIRT_SSBD_SPEC_CTRL if that is any better.

>Well, it's still required if the hypervisor wanted to allow the guest to turn
>off mitigations that are enabled in the host.  I'd omit this entirely and focus
>on what hardware does and how Linux/KVM utilize the new feature.

Ok. Sure.

>This line needs to be higher in the changelog, it's easily the most relevant
>info for understanding the mechanics.  Please also explicitly state the context
>switching mechanics, e.g. is it tracked in the VMCB, loaded on VMRUN, saved on
>VM-Exit, etc...

Will add more details.

>This will break migration, or maybe just cause wierdness, as userspace will
>always see '0' when reading SPEC_CTRL and its writes will be ignored.  Is there
>a VMCB field that holds the guest's value?  If so, this read can be skipped, and
>instead the MSR set/get flows probably need to poke into the VMCB.

Yes. The guest SEPC_CTRL value is saved in VMCB save area(i.e. 0x400 + 0x2E0).
Yes, will look into setting VMCB with the desired values in msr set/get if 
that helps.
Thanks
Babu