linux-kernel - Re: [GIT PULL] x86/shstk for 6.4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4433c3595db23f7c779b69b222958151b69ddd70.camel@intel.com>
Date:   Sat, 29 Apr 2023 00:26:37 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "Torvalds, Linus" <torvalds@...ux-foundation.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC:     "keescook@...omium.org" <keescook@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86/shstk for 6.4

On Fri, 2023-04-28 at 11:17 -0700, Linus Torvalds wrote:
> If it can be chopped up into smaller pieces ("this is just the
> preliminary work part which is all obvious and clear") that might
> help
> me, but I'll get around to it eventually regardless.

Looking at it with that in mind, I can see how the key bits have gotten
lost in the noise. I've taken a stab at reordering it. I think it is
better at separating out and tagging the boring parts from the thornier
ones.

The rebase was almost clean, and changes are pretty much in the commits
where they were originally. The robots are still checking it for
bisectability, so please consider this branch for review only.

The tags are as follows (in chronological order):

generic_mm
----------
Core MM refactoring in prep for shadow stack memory.

shadow_stack_prep
-----------------
Add Kconfig's and defines needed by later patches

saved_dirty
-----------
Implementation of the "Saved Dirty Bit". The HW has shadow stack as a
weird PTE bit combination: "Write=0,Dirty=1". So the x86 mm code keeps
track of the HW dirty bit in a SW bit when HW Dirty=1 memory gets
write-protected, in order to not inadvertently create shadow stack
memory.

shadow_stack_mem_boring
-----------------------
Shadow stack memory patches that are fairly mechanical.

shadow_stack_mem_thorny
-----------------------
The nitty gritty of shadow stack memory support.

shadow_stack_core
-----------------
This is the non-MM parts of the shadow stack implementation. It
implements new ABI around shadow stacks (clone, signals, enabling,
etc).

shadow_stack_ptrace
-------------------
Support for ptracers to work with/around shadow stack.


You might find generic_mm, shadow_stack_prep, shadow_stack_mem_boring
and shadow_stack_ptrace to be the most ordinary. And saved_dirty, 
shadow_stack_mem_thorny and shadow_stack_core to be more interesting.

Kindly placed on a host where the tags can be viewed in the commit log
by Dave:
https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=shadow_stack_ptrace