Re: [RFC PATCH 0/7] SVM guest shadow stack support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3/29/2023 8:16 AM, Yang, Weijiang wrote:

On 3/29/2023 1:51 AM, John Allen wrote:
On Wed, Jan 25, 2023 at 01:11:44AM +0000, Edgecombe, Rick P wrote:
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@xxxxxxxxx/
[2]: Latest CET kernel patches

https://lore.kernel.org/all/20220929222936.14584-1-rick.p.edgecombe@xxxxxxxxx/
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.
Now that the baremetal series has been accepted, how do we want to
proceed? I think I'd like to send a refreshed version based on the
version that was accpeted, but I'd want to wait to base it on a new
version of Weijiang's kvm/vmx series (if one is planned).

Weijiang and Rick,

Are you planning on sending a new version of the kvm/vmx series?

Hi, Allen,

Yes, I'm working on the new version of kvm/vmx series, will cc you when

send it to community.

Patch 1/7 did what I wanted to implement to support AMD SHSTK, my next version

will continue refactoring them in vmx scope, then  your series may pick up the helper

and modify accordingly.

Please note, in my series, I removed check for MSR_IA32_PL{0,1,2}_SSP since they're

not supported right now, but your series supports for the MSRs, so you have to change

the helper a bit to adapt to your patches.




Thanks,
John



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux