From: Chao Gao <chao.gao@intel.com>
To: "Yang, Weijiang" <weijiang.yang@intel.com>
Cc: Sean Christopherson <seanjc@google.com>,
Rick P Edgecombe <rick.p.edgecombe@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"john.allen@amd.com" <john.allen@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mlevitsk@redhat.com" <mlevitsk@redhat.com>
Subject: Re: [PATCH v8 00/26] Enable CET Virtualization
Date: Mon, 15 Jan 2024 09:55:43 +0800 [thread overview]
Message-ID: <ZaSQn7RCRTaBK1bc@chao-email> (raw)
In-Reply-To: <cf043809-430a-4072-b0fd-201cd469b602@intel.com>
On Thu, Jan 11, 2024 at 10:56:55PM +0800, Yang, Weijiang wrote:
>On 1/9/2024 11:10 PM, Sean Christopherson wrote:
>> On Mon, Jan 08, 2024, Weijiang Yang wrote:
>> > On 1/6/2024 12:21 AM, Sean Christopherson wrote:
>> > > On Fri, Jan 05, 2024, Weijiang Yang wrote:
>> > > > On 1/5/2024 8:54 AM, Sean Christopherson wrote:
>> > > > > On Fri, Jan 05, 2024, Rick P Edgecombe wrote:
>> > > > > > > For CALL/RET (and presumably any branch instructions with IBT?) other
>> > > > > > > instructions that are directly affected by CET, the simplest thing would
>> > > > > > > probably be to disable those in KVM's emulator if shadow stacks and/or IBT
>> > > > > > > are enabled, and let KVM's failure paths take it from there.
>> > > > > > Right, that is what I was wondering might be the normal solution for
>> > > > > > situations like this.
>> > > > > If KVM can't emulate something, it either retries the instruction (with some
>> > > > > decent logic to guard against infinite retries) or punts to userspace.
>> > > > What kind of error is proper if KVM has to punt to userspace?
>> > > KVM_INTERNAL_ERROR_EMULATION. See prepare_emulation_failure_exit().
>> > >
>> > > > Or just inject #UD into guest on detecting this case?
>> > > No, do not inject #UD or do anything else that deviates from architecturally
>> > > defined behavior.
>> > Thanks!
>> > But based on current KVM implementation and patch 24, seems that if CET is exposed
>> > to guest, the emulation code or shadow paging mode couldn't be activated at the same time:
>> No, requiring unrestricted guest only disables the paths where KVM *delibeately*
>> emulates the entire guest code stream. In no way, shape, or form does it prevent
>> KVM from attempting to emulate arbitrary instructions.
>
>Yes, also need to prevent sporadic emulation, how about adding below patch in emulator?
>
>
>diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
>index e223043ef5b2..e817d8560ceb 100644
>--- a/arch/x86/kvm/emulate.c
>+++ b/arch/x86/kvm/emulate.c
>@@ -178,6 +178,7 @@
> #define IncSP ((u64)1 << 54) /* SP is incremented before ModRM calc */
> #define TwoMemOp ((u64)1 << 55) /* Instruction has two memory operand */
> #define IsBranch ((u64)1 << 56) /* Instruction is considered a branch. */
>+#define IsProtected ((u64)1 << 57) /* Instruction is protected by CET. */
>
> #define DstXacc (DstAccLo | SrcAccHi | SrcWrite)
>
>@@ -4098,9 +4099,9 @@ static const struct opcode group4[] = {
> static const struct opcode group5[] = {
> F(DstMem | SrcNone | Lock, em_inc),
> F(DstMem | SrcNone | Lock, em_dec),
>- I(SrcMem | NearBranch | IsBranch, em_call_near_abs),
>- I(SrcMemFAddr | ImplicitOps | IsBranch, em_call_far),
>- I(SrcMem | NearBranch | IsBranch, em_jmp_abs),
>+ I(SrcMem | NearBranch | IsBranch | IsProtected, em_call_near_abs),
>+ I(SrcMemFAddr | ImplicitOps | IsBranch | IsProtected, em_call_far),
>+ I(SrcMem | NearBranch | IsBranch | IsProtected, em_jmp_abs),
> I(SrcMemFAddr | ImplicitOps | IsBranch, em_jmp_far),
> I(SrcMem | Stack | TwoMemOp, em_push), D(Undefined),
> };
>@@ -4362,11 +4363,11 @@ static const struct opcode opcode_table[256] = {
> /* 0xC8 - 0xCF */
> I(Stack | SrcImmU16 | Src2ImmByte | IsBranch, em_enter),
> I(Stack | IsBranch, em_leave),
>- I(ImplicitOps | SrcImmU16 | IsBranch, em_ret_far_imm),
>- I(ImplicitOps | IsBranch, em_ret_far),
>- D(ImplicitOps | IsBranch), DI(SrcImmByte | IsBranch, intn),
>+ I(ImplicitOps | SrcImmU16 | IsBranch | IsProtected, em_ret_far_imm),
>+ I(ImplicitOps | IsBranch | IsProtected, em_ret_far),
>+ D(ImplicitOps | IsBranch), DI(SrcImmByte | IsBranch | IsProtected, intn),
> D(ImplicitOps | No64 | IsBranch),
>- II(ImplicitOps | IsBranch, em_iret, iret),
>+ II(ImplicitOps | IsBranch | IsProtected, em_iret, iret),
> /* 0xD0 - 0xD7 */
> G(Src2One | ByteOp, group2), G(Src2One, group2),
> G(Src2CL | ByteOp, group2), G(Src2CL, group2),
>@@ -4382,7 +4383,7 @@ static const struct opcode opcode_table[256] = {
> I2bvIP(SrcImmUByte | DstAcc, em_in, in, check_perm_in),
> I2bvIP(SrcAcc | DstImmUByte, em_out, out, check_perm_out),
> /* 0xE8 - 0xEF */
>- I(SrcImm | NearBranch | IsBranch, em_call),
>+ I(SrcImm | NearBranch | IsBranch | IsProtected, em_call),
> D(SrcImm | ImplicitOps | NearBranch | IsBranch),
> I(SrcImmFAddr | No64 | IsBranch, em_jmp_far),
> D(SrcImmByte | ImplicitOps | NearBranch | IsBranch),
>@@ -4401,7 +4402,7 @@ static const struct opcode opcode_table[256] = {
> static const struct opcode twobyte_table[256] = {
> /* 0x00 - 0x0F */
> G(0, group6), GD(0, &group7), N, N,
>- N, I(ImplicitOps | EmulateOnUD | IsBranch, em_syscall),
>+ N, I(ImplicitOps | EmulateOnUD | IsBranch | IsProtected, em_syscall),
> II(ImplicitOps | Priv, em_clts, clts), N,
> DI(ImplicitOps | Priv, invd), DI(ImplicitOps | Priv, wbinvd), N, N,
> N, D(ImplicitOps | ModRM | SrcMem | NoAccess), N, N,
>@@ -4432,8 +4433,8 @@ static const struct opcode twobyte_table[256] = {
> IIP(ImplicitOps, em_rdtsc, rdtsc, check_rdtsc),
> II(ImplicitOps | Priv, em_rdmsr, rdmsr),
> IIP(ImplicitOps, em_rdpmc, rdpmc, check_rdpmc),
>- I(ImplicitOps | EmulateOnUD | IsBranch, em_sysenter),
>- I(ImplicitOps | Priv | EmulateOnUD | IsBranch, em_sysexit),
>+ I(ImplicitOps | EmulateOnUD | IsBranch | IsProtected, em_sysenter),
>+ I(ImplicitOps | Priv | EmulateOnUD | IsBranch | IsProtected, em_sysexit),
> N, N,
> N, N, N, N, N, N, N, N,
> /* 0x40 - 0x4F */
>@@ -4971,6 +4972,12 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void *insn, int insn_len, int
> if (ctxt->d == 0)
> return EMULATION_FAILED;
>+ if ((opcode.flags & IsProtected) &&
>+ (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_CET)) {
CR4.CET doesn't necessarily mean IBT or shadow stack is enabled. why not check
CPL and IA32_S/U_CET?
>+ WARN_ONCE(1, "CET is active, emulation aborted.\n");
remove this WARN_ONCE(). Guest can trigger this at will and overflow host dmesg.
if you really want to tell usespace the emulation_failure is due to CET, maybe
you can add a new flag like KVM_INTERNAL_ERROR_EMULATION_FLAG_INSTRUCTION_BYTES.
for now, I won't bother to add this because probably userspace just terminates
the VM on any instruction failure (i.e., won't try to figure out the reason of
the instruction failure and fix it).
next prev parent reply other threads:[~2024-01-15 1:55 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 14:02 [PATCH v8 00/26] Enable CET Virtualization Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 01/26] x86/fpu/xstate: Always preserve non-user xfeatures/flags in __state_perm Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 02/26] x86/fpu/xstate: Refine CET user xstate bit enabling Yang Weijiang
2024-01-02 22:24 ` Maxim Levitsky
2023-12-21 14:02 ` [PATCH v8 03/26] x86/fpu/xstate: Add CET supervisor mode state support Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 04/26] x86/fpu/xstate: Introduce XFEATURE_MASK_KERNEL_DYNAMIC xfeature set Yang Weijiang
2024-01-02 22:25 ` Maxim Levitsky
2024-01-03 9:10 ` Yang, Weijiang
2024-01-04 22:26 ` Edgecombe, Rick P
2024-01-04 22:26 ` Edgecombe, Rick P
2023-12-21 14:02 ` [PATCH v8 05/26] x86/fpu/xstate: Introduce fpu_guest_cfg for guest FPU configuration Yang Weijiang
2024-01-02 22:32 ` Maxim Levitsky
2024-01-03 9:17 ` Yang, Weijiang
2024-01-04 22:42 ` Edgecombe, Rick P
2023-12-21 14:02 ` [PATCH v8 06/26] x86/fpu/xstate: Create guest fpstate with guest specific config Yang Weijiang
2024-01-02 22:32 ` Maxim Levitsky
2024-01-03 18:16 ` Edgecombe, Rick P
2024-01-04 2:16 ` Yang, Weijiang
2024-01-04 22:47 ` Edgecombe, Rick P
2024-01-05 8:16 ` Yang, Weijiang
2023-12-21 14:02 ` [PATCH v8 07/26] x86/fpu/xstate: Warn if kernel dynamic xfeatures detected in normal fpstate Yang Weijiang
2024-01-02 22:33 ` Maxim Levitsky
2023-12-21 14:02 ` [PATCH v8 08/26] KVM: x86: Rework cpuid_get_supported_xcr0() to operate on vCPU data Yang Weijiang
2024-01-02 22:33 ` Maxim Levitsky
2023-12-21 14:02 ` [PATCH v8 09/26] KVM: x86: Rename kvm_{g,s}et_msr() to menifest emulation operations Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 10/26] KVM: x86: Refine xsave-managed guest register/MSR reset handling Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 11/26] KVM: x86: Add kvm_msr_{read,write}() helpers Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 12/26] KVM: x86: Report XSS as to-be-saved if there are supported features Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 13/26] KVM: x86: Refresh CPUID on write to guest MSR_IA32_XSS Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 14/26] KVM: x86: Initialize kvm_caps.supported_xss Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 15/26] KVM: x86: Load guest FPU state when access XSAVE-managed MSRs Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 16/26] KVM: x86: Add fault checks for guest CR4.CET setting Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 17/26] KVM: x86: Report KVM supported CET MSRs as to-be-saved Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 18/26] KVM: VMX: Introduce CET VMCS fields and control bits Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 19/26] KVM: x86: Use KVM-governed feature framework to track "SHSTK/IBT enabled" Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 20/26] KVM: VMX: Emulate read and write to CET MSRs Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 21/26] KVM: x86: Save and reload SSP to/from SMRAM Yang Weijiang
2024-01-02 22:34 ` Maxim Levitsky
2023-12-21 14:02 ` [PATCH v8 22/26] KVM: VMX: Set up interception for CET MSRs Yang Weijiang
2024-01-02 22:34 ` Maxim Levitsky
2024-01-15 9:58 ` Yuan Yao
2024-01-17 1:41 ` Yang, Weijiang
2024-01-17 1:58 ` Yang, Weijiang
2024-01-17 5:31 ` Yuan Yao
2024-01-17 6:16 ` Yang, Weijiang
2023-12-21 14:02 ` [PATCH v8 23/26] KVM: VMX: Set host constant supervisor states to VMCS fields Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 24/26] KVM: x86: Enable CET virtualization for VMX and advertise to userspace Yang Weijiang
2024-01-02 22:34 ` Maxim Levitsky
2024-01-16 7:25 ` Yuan Yao
2024-01-17 1:43 ` Yang, Weijiang
2023-12-21 14:02 ` [PATCH v8 25/26] KVM: nVMX: Introduce new VMX_BASIC bit for event error_code delivery to L1 Yang Weijiang
2023-12-21 14:02 ` [PATCH v8 26/26] KVM: nVMX: Enable CET support for nested guest Yang Weijiang
2024-01-02 22:35 ` Maxim Levitsky
2024-01-16 7:22 ` Yuan Yao
2024-01-17 1:53 ` Yang, Weijiang
2024-01-03 18:50 ` [PATCH v8 00/26] Enable CET Virtualization Edgecombe, Rick P
2024-01-04 7:11 ` Yang, Weijiang
2024-01-04 21:10 ` Edgecombe, Rick P
2024-01-05 0:22 ` Sean Christopherson
2024-01-05 0:34 ` Edgecombe, Rick P
2024-01-05 0:44 ` Jim Mattson
2024-01-05 0:54 ` Sean Christopherson
2024-01-05 9:28 ` Yang, Weijiang
2024-01-05 16:21 ` Sean Christopherson
2024-01-05 17:52 ` Edgecombe, Rick P
2024-01-05 18:09 ` Jim Mattson
2024-01-05 18:51 ` Edgecombe, Rick P
2024-01-05 19:34 ` Sean Christopherson
2024-01-08 14:17 ` Yang, Weijiang
2024-01-09 15:10 ` Sean Christopherson
2024-01-11 14:56 ` Yang, Weijiang
2024-01-15 1:55 ` Chao Gao [this message]
2024-01-17 0:53 ` Yang, Weijiang
2024-01-05 9:04 ` Yang, Weijiang
2024-01-04 22:29 ` Edgecombe, Rick P
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=ZaSQn7RCRTaBK1bc@chao-email \
--to=chao.gao@intel.com \
--cc=dave.hansen@intel.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=weijiang.yang@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