From: Sean Christopherson <seanjc@google.com>
To: John Allen <john.allen@amd.com>
Cc: Yang Weijiang <weijiang.yang@intel.com>,
pbonzini@redhat.com, jmattson@google.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, yu.c.zhang@linux.intel.com
Subject: Re: [PATCH v15 07/14] KVM: VMX: Emulate reads and writes to CET MSRs
Date: Wed, 18 May 2022 16:16:35 +0000 [thread overview]
Message-ID: <YoUb4/iP+X+xgsfQ@google.com> (raw)
In-Reply-To: <YoUW4Oh0eRL9um5m@dell9853host>
On Wed, May 18, 2022, John Allen wrote:
> On Wed, Feb 03, 2021 at 07:34:14PM +0800, Yang Weijiang wrote:
> > + case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
> > + if (!cet_is_ssp_msr_accessible(vcpu, msr_info))
> > + return 1;
> > + if ((data & GENMASK(2, 0)) || is_noncanonical_address(data, vcpu))
>
> Sorry to revive this old thread. I'm working on the corresponding SVM
> bits for shadow stack and I noticed the above check. Why isn't this
> GENMASK(1, 0)? The *SSP MSRs should be a 4-byte aligned canonical
> address meaning that just bits 1 and 0 should always be zero. I was
> looking through the previous versions of the set and found that this
> changed between versions 11 and 12, but I don't see any discussion
> related to this on the list.
Huh. I'm not entirely sure what to make of the SDM's wording:
The linear address written must be aligned to 8 bytes and bits 2:0 must be 0
(hardware requires bits 1:0 to be 0).
Looking at the rest of the CET stuff, I believe requiring 8-byte alignment is
correct, and that the "hardware requires" blurb is trying to call out that the
SSP stored in hardware will always be 4-byte aligned but not necessarily 8-byte
aligned in order to play nice with 32-bit/compatibility mode. But "base" addresses
that come from software, e.g. via MSRs and whatnot, must always be 8-byte aligned.
next prev parent reply other threads:[~2022-05-18 16:16 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 11:34 [PATCH v15 00/14] Introduce support for guest CET feature Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 01/14] KVM: x86: Report XSS as an MSR to be saved if there are supported features Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 02/14] KVM: x86: Refresh CPUID on writes to MSR_IA32_XSS Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 03/14] KVM: x86: Load guest fpu state when accessing MSRs managed by XSAVES Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 04/14] KVM: x86: Add #CP support in guest exception dispatch Yang Weijiang
2021-02-03 21:46 ` Sean Christopherson
2021-02-04 7:22 ` Yang Weijiang
2021-02-04 8:28 ` Paolo Bonzini
2021-02-04 8:24 ` Paolo Bonzini
2021-02-04 16:42 ` Sean Christopherson
2021-02-04 17:29 ` Paolo Bonzini
2021-02-03 11:34 ` [PATCH v15 05/14] KVM: VMX: Introduce CET VMCS fields and flags Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 06/14] KVM: x86: Add fault checks for CR4.CET Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 07/14] KVM: VMX: Emulate reads and writes to CET MSRs Yang Weijiang
2021-02-03 11:57 ` Paolo Bonzini
2021-02-03 12:50 ` Yang Weijiang
2022-05-18 15:55 ` John Allen
2022-05-18 16:16 ` Sean Christopherson [this message]
2022-05-19 8:49 ` Yang, Weijiang
2021-02-03 11:34 ` [PATCH v15 08/14] KVM: VMX: Add a synthetic MSR to allow userspace VMM to access GUEST_SSP Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 09/14] KVM: x86: Report CET MSRs as to-be-saved if CET is supported Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 10/14] KVM: x86: Enable CET virtualization for VMX and advertise CET to userspace Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 11/14] KVM: VMX: Pass through CET MSRs to the guest when supported Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 12/14] KVM: nVMX: Add helper to check the vmcs01 MSR bitmap for MSR pass-through Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 13/14] KVM: nVMX: Enable CET support for nested VMX Yang Weijiang
2021-02-03 11:34 ` [PATCH v15 14/14] KVM: x86: Save/Restore GUEST_SSP to/from SMRAM Yang Weijiang
2021-02-03 12:07 ` Paolo Bonzini
2021-02-03 12:59 ` Yang Weijiang
2021-02-03 12:40 ` [PATCH v15 00/14] Introduce support for guest CET feature Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YoUb4/iP+X+xgsfQ@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=weijiang.yang@intel.com \
--cc=yu.c.zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox