linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "Torvalds, Linus" <torvalds@linux-foundation.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Cc: "keescook@chromium.org" <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [GIT PULL] x86/shstk for 6.4
Date: Sat, 29 Apr 2023 00:26:37 +0000	[thread overview]
Message-ID: <4433c3595db23f7c779b69b222958151b69ddd70.camel@intel.com> (raw)
In-Reply-To: <CAHk-=whn3F1k263SZNUVQK195tcCMAo5E_WbmjUE0qFC5rWg=w@mail.gmail.com>

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

  reply	other threads:[~2023-04-29  0:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-24 21:21 [GIT PULL] x86/shstk for 6.4 Dave Hansen
2023-04-28 18:17 ` Linus Torvalds
2023-04-29  0:26   ` Edgecombe, Rick P [this message]
2023-04-29  0:40     ` Dave Hansen
2023-05-06 19:34       ` Linus Torvalds
2023-05-06 20:09         ` Linus Torvalds
2023-05-07  0:18           ` Edgecombe, Rick P
2023-05-07  0:38             ` Linus Torvalds
2023-05-07 15:57               ` Edgecombe, Rick P
2023-05-08 22:57           ` Dave Hansen
2023-05-08 23:31             ` Linus Torvalds
2023-05-08 23:47               ` Linus Torvalds
2023-05-12 17:34                 ` Dave Hansen
2023-05-12 21:55                   ` Linus Torvalds
2023-05-15 21:36                     ` Dave Hansen
2023-05-15 21:37                       ` Dave Hansen
2023-05-15 22:40                       ` Linus Torvalds
2023-05-15 23:02                         ` Linus Torvalds
2023-05-16 20:38                         ` Linus Torvalds
2023-05-16 20:42                           ` Dave Hansen
2023-05-09  0:07               ` Dave Hansen
2023-05-07  0:10         ` Edgecombe, Rick P
2023-05-07  0:19           ` Linus Torvalds
2023-05-07 16:24             ` Edgecombe, Rick P
2023-05-15 21:22               ` Deepak Gupta
2023-05-25 16:20                 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4433c3595db23f7c779b69b222958151b69ddd70.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).