[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <03de07df-da43-774f-3bb3-632455566053@intel.com>
Date: Mon, 24 Apr 2023 14:12:49 +0800
From: "Yang, Weijiang" <weijiang.yang@...el.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>
CC: <rick.p.edgecombe@...el.com>, <seanjc@...gle.com>,
<peterz@...radead.org>, <pbonzini@...hat.com>,
<kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<john.allen@....com>
Subject: Re: [PATCH v2 00/21] Enable CET Virtualization
On 4/23/2023 4:30 PM, Binbin Wu wrote:
>
> On 4/21/2023 9:45 PM, Yang Weijiang wrote:
[...]
>> Indirect Branch Tracking (IBT):
>> IBT adds new instrutions, ENDBRANCH{32|64}, to mark valid target
>> addresses
>
> /s/instrutions/instructions
Thanks for review, I'll fix these spelling issues.
>
>
>> of indirect branches (CALL, JMP etc...). If an indirect branch is
>> executed
>> and the next instruction is _not_ an ENDBRANCH, the processor
>> generates a #CP.
>
> IMHO, it's better to mention the behavior of the new instructions when
> IBT is not enabled or
> on the old platforms that don't support the feature.
Sure, will do it.
>
> [...]
>>
>> CET supervisor mode states are grouped into two categories - XSAVES
>> dependent
>> and non-dependent, the former includes MSR_IA32_PL{0,1,2}_SSP, the later
>> consists of MSR_IA32_S_CET and MSR_IA32_INTR_SSP_TBL. The XSAVES
>> dependent
>> MSR's save/restore depends on S_CET bit set in MSR_XSS. Since the
>> native series
>> doesn't enable S_CET support,
>
> Do you know the reason why native patch doesn't enable S_CET support?
This bit controls XSAVES for supervisor SHSTK, but the landing native
part is only for user SHSTK
so it doesn't need to touch it. Anyway, enabling the bit requires
additional FPU area size(3*8byte).
>
>
>> these s-SHSTK shadow stack pointers are invalid.
>>
>> Moveover, new VMCS fields, {GUEST|HOST}_{S_CET,SSP,INTR_SSP_TABL}, are
>> introduced for guest/host supervisor state switch. When CET
>> entry/exit load
>> bits are set, the guest/host MSR_IA32_{S_CET,INTR_SSP_TBL,SSP} are
>> swapped
>> automatically at vm-exit/entry. With these new fields, current guest
>> kernel
>> IBT enalbing doesn't depend on host {XSAVES|XRSTORS} support.
>
> /s/enalbing/enabling
>
>
>>
>>
>> Tests:
>> --------------------------------------------------------------------------
>>
>> This series passed basic CET user shadow stack test and kernel IBT
>> test in
>> L1 and L2 guest. It also passed CET KUT test which has been merged
>> there.
>>
>> Executed all KUT tests and KVM selftests against this series, all
>> test cases
>> passes except the vmx test, the failure is due to CR4_CET bit testing in
>> test_vmxon_bad_cr(). After add CR4_CET bit to skip list, the test
>> passed.
>> I'll send a patch to fix this issue later.
>>
>>
>> To run user shadow stack test and kernel IBT test in VM, you need an CET
>> capable platform, e.g., Sapphire Rapids server, and follow below
>> steps to
>> build host/guest kernel properly:
>>
>> 1. Buld host kernel. Patch this series to kernel tree and build kernel
>
> /s/Buld/Build
>
>
>> with CET capable gcc version(e.g., >=8.5.0).
>
> I guess these should be some compiler option(s), can you also list it
> here if any?
Please check gcc options: -fcf-protection=[full|branch|return|none]
>
>
>>
>> 2. Build guest kernel. Patch CET native series to kernel tree and opt-in
>> CONFIG_X86_KERNEL_IBT and CONFIG_X86_USER_SHADOW_STACK options.
>
> I guess guest kernel also needs to be built using CET capable tool
> chain with CET enabled?
Yes.
For kernel IBT testing, KERNEL_IBT option + CET enabled tool chain is a
must.
>
>
[...]
Powered by blists - more mailing lists