Re: [PATCH v2 23/39] x86: Introduce userspace API for CET enabling

2 messages, 2 authors, 2022-10-12 · open the first message on its own page

Re: [PATCH v2 23/39] x86: Introduce userspace API for CET enabling

From: Florian Weimer <hidden>
Date: 2022-10-12 12:19:15

* Rick P. Edgecombe:
On Mon, 2022-10-10 at 12:56 +0200, Florian Weimer wrote:
quoted
quoted
+     /* Only support enabling/disabling one feature at a time. */
+     if (hweight_long(features) > 1)
+             return -EINVAL;
This means we'll soon need three extra system calls for x86-64
process
start: SHSTK, IBT, and switching off vsyscall emulation.  (The latter
does not need any special CPU support.)

Maybe we can do something else instead to make the strace output a
little bit cleaner?
In previous versions it supported enabling multiple features in a
single syscall. Thomas Gleixner pointed out that (this was on the LAM
patchset that shared the interface at the time) it makes the behavior
of what to do when one feature fails to enable complicated:

https://lore.kernel.org/lkml/87zgjjqico.ffs@tglx/
Can we return the bits for the features that were actually enabled?
Those three don't have cross-dependencies in the sense that you would
only use X & Y together, but not X or Y alone.

Thanks,
Florian

Re: [PATCH v2 23/39] x86: Introduce userspace API for CET enabling

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: 2022-10-12 17:30:36

On Wed, 2022-10-12 at 14:18 +0200, Florian Weimer wrote:
* Rick P. Edgecombe:
quoted
On Mon, 2022-10-10 at 12:56 +0200, Florian Weimer wrote:
quoted
quoted
+     /* Only support enabling/disabling one feature at a time.
*/
+     if (hweight_long(features) > 1)
+             return -EINVAL;
This means we'll soon need three extra system calls for x86-64
process
start: SHSTK, IBT, and switching off vsyscall emulation.  (The
latter
does not need any special CPU support.)

Maybe we can do something else instead to make the strace output
a
little bit cleaner?
In previous versions it supported enabling multiple features in a
single syscall. Thomas Gleixner pointed out that (this was on the
LAM
patchset that shared the interface at the time) it makes the
behavior
of what to do when one feature fails to enable complicated:

https://lore.kernel.org/lkml/87zgjjqico.ffs@tglx/
Can we return the bits for the features that were actually enabled?
Actually that specific option is covered in that thread as well. I was
thinking we would need to pass a struct in an out to do a batch
operation. Thomas suggested it could be added later and to start with a
simpler option. Is an extra syscall or two at startup really a big
problem?
Those three don't have cross-dependencies in the sense that you would
only use X & Y together, but not X or Y alone.
I don't fully follow this, but WRSS does actually depend on SHSTK.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help