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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ