Thread (66 messages) 66 messages, 5 authors, 2021-03-29

Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack

From: Ingo Molnar <mingo@kernel.org>
Date: 2021-03-17 09:18:47
Also in: linux-arch, linux-doc, linux-mm, lkml

* Yu, Yu-cheng [off-list ref] wrote:
On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
quoted
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
quoted
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks.  Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].

CET can protect applications and the kernel.  This series enables only
application-level protection, and has three parts:

   - Shadow stack [2],
   - Indirect branch tracking [3], and
   - Selftests [4].
CET is marketing; afaict SS and IBT are 100% independent and there's no
reason what so ever to have them share any code, let alone a Kconfig
knob.
We used to have shadow stack and ibt under separate Kconfig options, but in
a few places they actually share same code path, such as the XSAVES
supervisor states and ELF header for example.  Anyways I will be happy to
make changes again if there is agreement.
I was look at:

  x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states

didn't see any IBT logic - it's essentially all shadow stack state.

Which is not surprising, forward call edge integrity protection (IBT) 
requires very little state, does it?

With IBT there's no nesting, no stack - the IBT state machine 
basically requires the next instruction to be and ENDBR instruction, 
and that's essentially it, right?

Thanks,

	Ingo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help