Re: [PATCH v15 03/26] x86/fpu/xstate: Introduce CET MSR XSAVES supervisor states

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

 



On 12/1/2020 2:26 PM, Dave Hansen wrote:
On 11/30/20 3:16 PM, Yu, Yu-cheng wrote:

Do we have any other spots in the kernel where we care about:

     boot_cpu_has(X86_FEATURE_SHSTK) ||
     boot_cpu_has(X86_FEATURE_IBT)

?  If so, we could also address this by declaring a software-defined
X86_FEATURE_CET and then setting it if SHSTK||IBT is supported, then we
just put that one feature in xsave_cpuid_features[].


These features have different CPUIDs but are complementary parts.  I
don't know if someday there will be shadow-stack-only CPUs, but an
IBT-only CPU is weird.  What if the kernel checks that the CPU has both
features and presents only one feature flag (X86_FEATURE_CET), no
X86_FEATURE_SHSTK or X86_FEATURE_IBT?

Logically, that's probably fine.  But, X86_FEATURE_IBT/SHSTK are in a
non-scattered leaf, so we'll kinda define them whether we like it or
not.  We'd have to go out of our way to *not* define them.


After more thoughts, I think it is better to just add X86_FEATURE_CET and not more. We cannot predict what is going to happen later. So, like what you suggested, X86_FEATURE_CET means (X86_FEATURE_SHSTK | X86_FEATURE_IBT).

Thanks,
Yu-cheng




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux