From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "Christopherson,, Sean" <seanjc@google.com>,
"john.allen@amd.com" <john.allen@amd.com>
Cc: "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"Yang, Weijiang" <weijiang.yang@intel.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC PATCH 0/7] SVM guest shadow stack support
Date: Wed, 25 Jan 2023 01:11:44 +0000 [thread overview]
Message-ID: <d4e15021af4e72d6daba4021feaebf289b676830.camel@intel.com> (raw)
In-Reply-To: <Y9B97dZnFnjEHhVf@google.com>
On Wed, 2023-01-25 at 00:55 +0000, Sean Christopherson wrote:
> On Wed, Oct 12, 2022, John Allen wrote:
> > AMD Zen3 and newer processors support shadow stack, a feature
> > designed to
> > protect against ROP (return-oriented programming) attacks in which
> > an attacker
> > manipulates return addresses on the call stack in order to execute
> > arbitrary
> > code. To prevent this, shadow stacks can be allocated that are only
> > used by
> > control transfer and return instructions. When a CALL instruction
> > is issued, it
> > writes the return address to both the program stack and the shadow
> > stack. When
> > the subsequent RET instruction is issued, it pops the return
> > address from both
> > stacks and compares them. If the addresses don't match, a control-
> > protection
> > exception is raised.
> >
> > Shadow stack and a related feature, Indirect Branch Tracking (IBT),
> > are
> > collectively referred to as Control-flow Enforcement Technology
> > (CET). However,
> > current AMD processors only support shadow stack and not IBT.
> >
> > This series adds support for shadow stack in SVM guests and builds
> > upon the
> > support added in the CET guest support patch series [1] and the CET
> > kernel
> > patch series [2]. Additional patches are required to support shadow
> > stack
> > enabled guests in qemu [3] and glibc [4].
> >
> > [1]: CET guest support patches
> >
https://lore.kernel.org/all/20220616084643.19564-1-weijiang.yang@intel.com/
> >
> > [2]: Latest CET kernel patches
> >
https://lore.kernel.org/all/20220929222936.14584-1-rick.p.edgecombe@intel.com/
>
> That dependency chain makes me sad.
>
> Outside of a very shallow comment on the last patch, I don't plan on
> reviewing
> this until the kernel side of things gets out of our way. When that
> finally
> does happen, I'll definitely prioritize reviewing and merging this
> and the KVM
> Intel series. I'd love to see this land.
I think all KVM needs is a few patches from the beginning of the host
series (the FPU stuff). At one point Weijiang and I had discussed with
Paolo and x86 folks that those few could go up with the KVM series if
desired.
next prev parent reply other threads:[~2023-01-25 1:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-12 20:39 [RFC PATCH 0/7] SVM guest shadow stack support John Allen
2022-10-12 20:39 ` [RFC PATCH 1/7] KVM: x86: Move shared CET routine to common x86 kvm code John Allen
2022-10-12 20:39 ` [RFC PATCH 2/7] KVM: x86: SVM: Emulate reads and writes to shadow stack MSRs John Allen
2022-10-12 20:39 ` [RFC PATCH 3/7] KVM: x86: SVM: Update dump_vmcb with shadow stack save area additions John Allen
2022-10-12 20:39 ` [RFC PATCH 4/7] KVM: x86: SVM: Pass through shadow stack MSRs John Allen
2022-10-12 20:39 ` [RFC PATCH 5/7] KVM: SVM: Save shadow stack host state on VMRUN John Allen
2022-10-12 20:39 ` [RFC PATCH 6/7] KVM: SVM: Add MSR_IA32_XSS to the GHCB for hypervisor kernel John Allen
2022-10-12 20:39 ` [RFC PATCH 7/7] KVM: SVM: Add CET features to supported_xss John Allen
2023-01-25 0:51 ` Sean Christopherson
2023-01-25 0:55 ` [RFC PATCH 0/7] SVM guest shadow stack support Sean Christopherson
2023-01-25 1:11 ` Edgecombe, Rick P [this message]
2023-03-28 17:51 ` John Allen
2023-03-29 0:16 ` Yang, Weijiang
2023-03-30 5:37 ` Yang, Weijiang
2023-03-30 19:47 ` John Allen
2023-03-30 20:05 ` Sean Christopherson
2023-03-31 6:39 ` Yang, Weijiang
2023-01-25 17:07 ` John Allen
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=d4e15021af4e72d6daba4021feaebf289b676830.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.org \
/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