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

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

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?

Those are better.

quoted

quoted

+	no_cet_ibt	[X86-64] Disable Indirect Branch Tracking for user-mode
+			applications
+
 	nosmap		[X86,PPC]
 			Disable SMAP (Supervisor Mode Access Prevention)
 			even if it is supported by processor.

BTW, this documentation is misplaced.  It needs to go to the spot where
you introduce the code for these options.

We used to introduce the document later in the series.  The feedback was to
introduce it first so that readers know what to expect.

To me, that doesn't apply for things that are implemented in this
specific of a spot in the code and *ALSO* might not even make the final
series.

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?

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.

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?