Re: [RFC PATCH v9 01/27] Documentation/x86: Add CET description

On Mon, 2020-03-09 at 10:21 -0700, Dave Hansen wrote:

On 3/9/20 10:00 AM, Yu-cheng Yu wrote:

quoted

On Wed, 2020-02-26 at 09:57 -0800, Dave Hansen wrote:

quoted

quoted

index ade4e6ec23e0..8b69ebf0baed 100644

--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt

@@ -3001,6 +3001,12 @@
 			noexec=on: enable non-executable mappings (default)
 			noexec=off: disable non-executable mappings
 
+	no_cet_shstk	[X86-64] Disable Shadow Stack for user-mode
+			applications

If we ever add kernel support, "no_cet_shstk" will mean "no cet shstk
for userspace"?

What about no_user_shstk, no_kernel_shstk?

[...]

quoted

quoted

quoted

+Note:
+  There is no CET-enabling arch_prctl function.  By design, CET is
+  enabled automatically if the binary and the system can support it.

This is kinda interesting.  It means that a JIT couldn't choose to
protect the code it generates and have different rules from itself?

JIT needs to be updated for CET first.  Once that is done, it runs with CET
enabled.  It can use the NOTRACK prefix, for example.

Am I missing something?

What's the direct connection between shadow stacks and Indirect Branch
Tracking other than Intel marketing umbrellas?

What I meant is that JIT code needs to be updated first; if it skips RETs,
it needs to unwind the stack, and if it does indirect JMPs somewhere it
needs to fix up the branch target or use NOTRACK.

quoted

quoted

quoted

+  The parameters passed are always unsigned 64-bit.  When an IA32
+  application passing pointers, it should only use the lower 32 bits.

Won't a 32-bit app calling prctl() use the 32-bit ABI?  How would it
even know it's running on a 64-bit kernel?

The 32-bit app is passing only a pointer to an array of 64-bit numbers.

Well, the documentation just talked about pointers and I naively assume
it means the "unsigned long *" you had in there.

Rather than make suggestions, just say that the ABI is universally
64-bit.  Saying that the pointers must be valid is just kinda silly.
It's also not 100% clear what an "IA32 application" *MEANS* given fun
things like x32.

Ok, I will update the text.

Also, I went to go find this implementation in your series.  I couldn't
find it.  Did I miss a patch?  Or are you documenting things you didn't
even implement?

In patch #27: Add arch_prctl functions for Shadow Stack.

Yu-cheng