| Message ID | 20230613001108.3040476-1-rick.p.edgecombe@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Shadow stacks for userspace | expand |
On Mon, Jun 12, 2023 at 5:14 PM Rick Edgecombe <rick.p.edgecombe@intel.com> wrote: > > This series implements Shadow Stacks for userspace using x86's Control-flow > Enforcement Technology (CET). Do you have this in a git tree somewhere? For series with this many patches, I find it easier to just do a "git fetch" and "gitk ..FETCH_HEAD" these days, and then reply by email on anything I find. That's partly because it makes it really easy to zoom in on some particular area (eg "let's look at just mm/ and the generic include files") Linus
On Mon, 2023-06-12 at 18:34 -0700, Linus Torvalds wrote: > On Mon, Jun 12, 2023 at 5:14 PM Rick Edgecombe > <rick.p.edgecombe@intel.com> wrote: > > > > This series implements Shadow Stacks for userspace using x86's > > Control-flow > > Enforcement Technology (CET). > > Do you have this in a git tree somewhere? For series with this many > patches, I find it easier to just do a "git fetch" and "gitk > ..FETCH_HEAD" these days, and then reply by email on anything I find. > > That's partly because it makes it really easy to zoom in on some > particular area (eg "let's look at just mm/ and the generic include > files") Sure. I probably should have included that upfront. Here is a github repo: https://github.com/rpedgeco/linux/tree/user_shstk_v9 I went ahead and included the tags[0] from last time in case that's useful, but unfortunately the github web interface is not very conducive to viewing the tag-based segmentation of the series. If having it in a korg repo would be useful, please let me know. [0] https://lore.kernel.org/lkml/4433c3595db23f7c779b69b222958151b69ddd70.camel@intel.com/
On Mon, Jun 12, 2023 at 8:12 PM Edgecombe, Rick P <rick.p.edgecombe@intel.com> wrote: > > Sure. I probably should have included that upfront. Here is a github > repo: > https://github.com/rpedgeco/linux/tree/user_shstk_v9 > > I went ahead and included the tags[0] from last time in case that's > useful, but unfortunately the github web interface is not very > conducive to viewing the tag-based segmentation of the series. If > having it in a korg repo would be useful, please let me know. Oh, kernel.org vs github doesn't matter. I'm not actually merging this yet, I'm just doing a fetch to then easily be able to look at it locally in different formats. I tend to like seeing small things in my MUA just because then I don't switch back-and-forth between reading email and some gitk workflow, and it is easy to just scan through the series and reply all inthe MUA. But when it's some bigger piece, just doing a "git fetch" and then being able to dissect it locally is really convenient. Having worked with patches for three decades, I can read diffs in my sleep - but it's still quite useful to say "give me the patches just for *this* file" to just see how some specific area changed without having to look at the other parts. Or for example, that whole pte_mkwrite -> pte_mkwrite_novma patch is much denser and more legible with color-coding and the --word-diff. Anyway, I'm scanning through it right now. No comments yet, I only just got started. Linus
On Tue, Jun 13, 2023 at 10:44 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Anyway, I'm scanning through it right now. No comments yet, I only > just got started. Well, it all looked fine from a quick scan. One small comment, and even that was just a minor stylistic nit. I didn't actually look through the x86 state infrastructure side - I'll just trust that is fine, and it doesn't interact with anything else, so I don't really worry about it. I mainly care about the VM side not causing problems, and the changes on that side all looked fine. Linus
On Tue, 2023-06-13 at 11:27 -0700, Linus Torvalds wrote: > On Tue, Jun 13, 2023 at 10:44 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > Anyway, I'm scanning through it right now. No comments yet, I only > > just got started. > > Well, it all looked fine from a quick scan. One small comment, and > even that was just a minor stylistic nit. > > I didn't actually look through the x86 state infrastructure side - > I'll just trust that is fine, and it doesn't interact with anything > else, so I don't really worry about it. I mainly care about the VM > side not causing problems, and the changes on that side all looked > fine. Thanks!
On Mon, Jun 12, 2023 at 05:10:26PM -0700, Rick Edgecombe wrote: > This series implements Shadow Stacks for userspace using x86's Control-flow > Enforcement Technology (CET). CET consists of two related security > features: shadow stacks and indirect branch tracking. This series > implements just the shadow stack part of this feature, and just for > userspace. I've been using the generic changes here for the work I've been doing on arm64's similar GCS feature, while that is still very much WIP and hasn't been posted anywhere most of the common code here has been exercised. I've been through the patches that I've specifically checked or used. Thanks for all the work here.