Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Mon, Jul 17, 2023 at 03:55:50PM +, Edgecombe, Rick P wrote: > On Fri, 2023-07-14 at 23:57 +0100, Mark Brown wrote: > > The same issue seems to apply with the version that was in -next > > based > > on v6.4-rc4 too. > The version in your branch is not the same as the version in tip (which > had a squashed build fix). I was able to reproduce the build error with > your branch. But not with the one in tip rebased on v6.5-rc1. So can > you try this version: > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/shstk=899223d69ce9f338056f4c41ef870d70040fc860 Ah, I'd not seen that patch or that tip had been rebased - I'd actually been using literally the branch from tip as my base at whatever point I last noticed it changing up until I rebased onto -rc1. signature.asc Description: PGP signature
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Fri, 2023-07-14 at 23:57 +0100, Mark Brown wrote:
> On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote:
> > The x86 Shadow stack feature includes a new type of memory called
> > shadow
> > stack. This shadow stack memory has some unusual properties, which
> > requires
> > some core mm changes to function properly.
>
> This seems to break sparc64_defconfig when applied on top of v6.5-
> rc1:
>
> In file included from /home/broonie/git/bisect/include/linux/mm.h:29,
> from /home/broonie/git/bisect/net/core/skbuff.c:40:
> /home/broonie/git/bisect/include/linux/pgtable.h: In function
> 'pmd_mkwrite':
> /home/broonie/git/bisect/include/linux/pgtable.h:528:9: error:
> implicit declaration of function 'pmd_mkwrite_novma'; did you mean
> 'pte_mkwrite_novma'? [-Werror=implicit-function-declaration]
> return pmd_mkwrite_novma(pmd);
> ^
> pte_mkwrite_novma
> /home/broonie/git/bisect/include/linux/pgtable.h:528:9: error:
> incompatible types when returning type 'int' but 'pmd_t' {aka 'struct
> '} was expected
> return pmd_mkwrite_novma(pmd);
> ^~
>
> The same issue seems to apply with the version that was in -next
> based
> on v6.4-rc4 too.
The version in your branch is not the same as the version in tip (which
had a squashed build fix). I was able to reproduce the build error with
your branch. But not with the one in tip rebased on v6.5-rc1. So can
you try this version:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/shstk=899223d69ce9f338056f4c41ef870d70040fc860
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote:
> The x86 Shadow stack feature includes a new type of memory called shadow
> stack. This shadow stack memory has some unusual properties, which requires
> some core mm changes to function properly.
This seems to break sparc64_defconfig when applied on top of v6.5-rc1:
In file included from /home/broonie/git/bisect/include/linux/mm.h:29,
from /home/broonie/git/bisect/net/core/skbuff.c:40:
/home/broonie/git/bisect/include/linux/pgtable.h: In function 'pmd_mkwrite':
/home/broonie/git/bisect/include/linux/pgtable.h:528:9: error: implicit
declaration of function 'pmd_mkwrite_novma'; did you mean 'pte_mkwrite_novma'?
[-Werror=implicit-function-declaration]
return pmd_mkwrite_novma(pmd);
^
pte_mkwrite_novma
/home/broonie/git/bisect/include/linux/pgtable.h:528:9: error: incompatible
types when returning type 'int' but 'pmd_t' {aka 'struct '} was
expected
return pmd_mkwrite_novma(pmd);
^~
The same issue seems to apply with the version that was in -next based
on v6.4-rc4 too.
signature.asc
Description: PGP signature
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Tue, 2023-06-13 at 09:19 +0200, Geert Uytterhoeven wrote: > Acked-by: Geert Uytterhoeven Thanks!
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Tue, 2023-06-13 at 10:43 +0300, Mike Rapoport wrote: > On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote: > > The x86 Shadow stack feature includes a new type of memory called > > shadow > > stack. This shadow stack memory has some unusual properties, which > > requires > > some core mm changes to function properly. > > > > One of these unusual properties is that shadow stack memory is > > writable, > > but only in limited ways. These limits are applied via a specific > > PTE > > bit combination. Nevertheless, the memory is writable, and core mm > > code > > will need to apply the writable permissions in the typical paths > > that > > call pte_mkwrite(). Future patches will make pte_mkwrite() take a > > VMA, so > > that the x86 implementation of it can know whether to create > > regular > > writable memory or shadow stack memory. > > Nit: ^ mapping? Hmm, sure. > > > But there are a couple of challenges to this. Modifying the > > signatures of > > each arch pte_mkwrite() implementation would be error prone because > > some > > are generated with macros and would need to be re-implemented. > > Also, some > > pte_mkwrite() callers operate on kernel memory without a VMA. > > > > So this can be done in a three step process. First pte_mkwrite() > > can be > > renamed to pte_mkwrite_novma() in each arch, with a generic > > pte_mkwrite() > > added that just calls pte_mkwrite_novma(). Next callers without a > > VMA can > > be moved to pte_mkwrite_novma(). And lastly, pte_mkwrite() and all > > callers > > can be changed to take/pass a VMA. > > > > Start the process by renaming pte_mkwrite() to pte_mkwrite_novma() > > and > > adding the pte_mkwrite() wrapper in linux/pgtable.h. Apply the same > > pattern for pmd_mkwrite(). Since not all archs have a > > pmd_mkwrite_novma(), > > create a new arch config HAS_HUGE_PAGE that can be used to tell if > > pmd_mkwrite() should be defined. Otherwise in the !HAS_HUGE_PAGE > > cases the > > compiler would not be able to find pmd_mkwrite_novma(). > > > > No functional change. > > > > Cc: linux-...@vger.kernel.org > > Cc: linux-ker...@vger.kernel.org > > Cc: linux-al...@vger.kernel.org > > Cc: linux-snps-...@lists.infradead.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: linux-c...@vger.kernel.org > > Cc: linux-hexa...@vger.kernel.org > > Cc: linux-i...@vger.kernel.org > > Cc: loonga...@lists.linux.dev > > Cc: linux-m...@lists.linux-m68k.org > > Cc: Michal Simek > > Cc: Dinh Nguyen > > Cc: linux-m...@vger.kernel.org > > Cc: openr...@lists.librecores.org > > Cc: linux-par...@vger.kernel.org > > Cc: linuxppc-dev@lists.ozlabs.org > > Cc: linux-ri...@lists.infradead.org > > Cc: linux-s...@vger.kernel.org > > Cc: linux...@vger.kernel.org > > Cc: sparcli...@vger.kernel.org > > Cc: linux...@lists.infradead.org > > Cc: linux-a...@vger.kernel.org > > Cc: linux...@kvack.org > > Suggested-by: Linus Torvalds > > Signed-off-by: Rick Edgecombe > > Link: > > https://lore.kernel.org/lkml/CAHk-=wizjsu7c9sfyzb3q04108stghff2wfbokgccgw7riz...@mail.gmail.com/ > > Reviewed-by: Mike Rapoport (IBM) Thanks!
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Tue, 2023-06-13 at 14:26 +0200, David Hildenbrand wrote: > > Acked-by: David Hildenbrand Thanks!
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On 13.06.23 02:10, Rick Edgecombe wrote: The x86 Shadow stack feature includes a new type of memory called shadow stack. This shadow stack memory has some unusual properties, which requires some core mm changes to function properly. One of these unusual properties is that shadow stack memory is writable, but only in limited ways. These limits are applied via a specific PTE bit combination. Nevertheless, the memory is writable, and core mm code will need to apply the writable permissions in the typical paths that call pte_mkwrite(). Future patches will make pte_mkwrite() take a VMA, so that the x86 implementation of it can know whether to create regular writable memory or shadow stack memory. But there are a couple of challenges to this. Modifying the signatures of each arch pte_mkwrite() implementation would be error prone because some are generated with macros and would need to be re-implemented. Also, some pte_mkwrite() callers operate on kernel memory without a VMA. So this can be done in a three step process. First pte_mkwrite() can be renamed to pte_mkwrite_novma() in each arch, with a generic pte_mkwrite() added that just calls pte_mkwrite_novma(). Next callers without a VMA can be moved to pte_mkwrite_novma(). And lastly, pte_mkwrite() and all callers can be changed to take/pass a VMA. Start the process by renaming pte_mkwrite() to pte_mkwrite_novma() and adding the pte_mkwrite() wrapper in linux/pgtable.h. Apply the same pattern for pmd_mkwrite(). Since not all archs have a pmd_mkwrite_novma(), create a new arch config HAS_HUGE_PAGE that can be used to tell if pmd_mkwrite() should be defined. Otherwise in the !HAS_HUGE_PAGE cases the compiler would not be able to find pmd_mkwrite_novma(). No functional change. Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-al...@vger.kernel.org Cc: linux-snps-...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-c...@vger.kernel.org Cc: linux-hexa...@vger.kernel.org Cc: linux-i...@vger.kernel.org Cc: loonga...@lists.linux.dev Cc: linux-m...@lists.linux-m68k.org Cc: Michal Simek Cc: Dinh Nguyen Cc: linux-m...@vger.kernel.org Cc: openr...@lists.librecores.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ri...@lists.infradead.org Cc: linux-s...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: linux...@lists.infradead.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org Suggested-by: Linus Torvalds Signed-off-by: Rick Edgecombe Link: https://lore.kernel.org/lkml/CAHk-=wizjsu7c9sfyzb3q04108stghff2wfbokgccgw7riz...@mail.gmail.com/ --- Hi Non-x86 Arch’s, x86 has a feature that allows for the creation of a special type of writable memory (shadow stack) that is only writable in limited specific ways. Previously, changes were proposed to core MM code to teach it to decide when to create normally writable memory or the special shadow stack writable memory, but David Hildenbrand suggested[0] to change pXX_mkwrite() to take a VMA, so awareness of shadow stack memory can be moved into x86 code. Later Linus suggested a less error-prone way[1] to go about this after the first attempt had a bug. Since pXX_mkwrite() is defined in every arch, it requires some tree-wide changes. So that is why you are seeing some patches out of a big x86 series pop up in your arch mailing list. There is no functional change. After this refactor, the shadow stack series goes on to use the arch helpers to push arch memory details inside arch/x86 and other arch's with upcoming shadow stack features. Testing was just 0-day build testing. Hopefully that is enough context. Thanks! [0] https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/ [1] https://lore.kernel.org/lkml/CAHk-=wizjsu7c9sfyzb3q04108stghff2wfbokgccgw7riz...@mail.gmail.com/ --- Acked-by: David Hildenbrand -- Cheers, David / dhildenb
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote: > The x86 Shadow stack feature includes a new type of memory called shadow > stack. This shadow stack memory has some unusual properties, which requires > some core mm changes to function properly. > > One of these unusual properties is that shadow stack memory is writable, > but only in limited ways. These limits are applied via a specific PTE > bit combination. Nevertheless, the memory is writable, and core mm code > will need to apply the writable permissions in the typical paths that > call pte_mkwrite(). Future patches will make pte_mkwrite() take a VMA, so > that the x86 implementation of it can know whether to create regular > writable memory or shadow stack memory. Nit:^ mapping? > But there are a couple of challenges to this. Modifying the signatures of > each arch pte_mkwrite() implementation would be error prone because some > are generated with macros and would need to be re-implemented. Also, some > pte_mkwrite() callers operate on kernel memory without a VMA. > > So this can be done in a three step process. First pte_mkwrite() can be > renamed to pte_mkwrite_novma() in each arch, with a generic pte_mkwrite() > added that just calls pte_mkwrite_novma(). Next callers without a VMA can > be moved to pte_mkwrite_novma(). And lastly, pte_mkwrite() and all callers > can be changed to take/pass a VMA. > > Start the process by renaming pte_mkwrite() to pte_mkwrite_novma() and > adding the pte_mkwrite() wrapper in linux/pgtable.h. Apply the same > pattern for pmd_mkwrite(). Since not all archs have a pmd_mkwrite_novma(), > create a new arch config HAS_HUGE_PAGE that can be used to tell if > pmd_mkwrite() should be defined. Otherwise in the !HAS_HUGE_PAGE cases the > compiler would not be able to find pmd_mkwrite_novma(). > > No functional change. > > Cc: linux-...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-al...@vger.kernel.org > Cc: linux-snps-...@lists.infradead.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-c...@vger.kernel.org > Cc: linux-hexa...@vger.kernel.org > Cc: linux-i...@vger.kernel.org > Cc: loonga...@lists.linux.dev > Cc: linux-m...@lists.linux-m68k.org > Cc: Michal Simek > Cc: Dinh Nguyen > Cc: linux-m...@vger.kernel.org > Cc: openr...@lists.librecores.org > Cc: linux-par...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-ri...@lists.infradead.org > Cc: linux-s...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: sparcli...@vger.kernel.org > Cc: linux...@lists.infradead.org > Cc: linux-a...@vger.kernel.org > Cc: linux...@kvack.org > Suggested-by: Linus Torvalds > Signed-off-by: Rick Edgecombe > Link: > https://lore.kernel.org/lkml/CAHk-=wizjsu7c9sfyzb3q04108stghff2wfbokgccgw7riz...@mail.gmail.com/ Reviewed-by: Mike Rapoport (IBM) -- Sincerely yours, Mike.
Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()
On Tue, Jun 13, 2023 at 2:13 AM Rick Edgecombe
wrote:
> The x86 Shadow stack feature includes a new type of memory called shadow
> stack. This shadow stack memory has some unusual properties, which requires
> some core mm changes to function properly.
>
> One of these unusual properties is that shadow stack memory is writable,
> but only in limited ways. These limits are applied via a specific PTE
> bit combination. Nevertheless, the memory is writable, and core mm code
> will need to apply the writable permissions in the typical paths that
> call pte_mkwrite(). Future patches will make pte_mkwrite() take a VMA, so
> that the x86 implementation of it can know whether to create regular
> writable memory or shadow stack memory.
>
> But there are a couple of challenges to this. Modifying the signatures of
> each arch pte_mkwrite() implementation would be error prone because some
> are generated with macros and would need to be re-implemented. Also, some
> pte_mkwrite() callers operate on kernel memory without a VMA.
>
> So this can be done in a three step process. First pte_mkwrite() can be
> renamed to pte_mkwrite_novma() in each arch, with a generic pte_mkwrite()
> added that just calls pte_mkwrite_novma(). Next callers without a VMA can
> be moved to pte_mkwrite_novma(). And lastly, pte_mkwrite() and all callers
> can be changed to take/pass a VMA.
>
> Start the process by renaming pte_mkwrite() to pte_mkwrite_novma() and
> adding the pte_mkwrite() wrapper in linux/pgtable.h. Apply the same
> pattern for pmd_mkwrite(). Since not all archs have a pmd_mkwrite_novma(),
> create a new arch config HAS_HUGE_PAGE that can be used to tell if
> pmd_mkwrite() should be defined. Otherwise in the !HAS_HUGE_PAGE cases the
> compiler would not be able to find pmd_mkwrite_novma().
>
> No functional change.
>
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-al...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c...@vger.kernel.org
> Cc: linux-hexa...@vger.kernel.org
> Cc: linux-i...@vger.kernel.org
> Cc: loonga...@lists.linux.dev
> Cc: linux-m...@lists.linux-m68k.org
> Cc: Michal Simek
> Cc: Dinh Nguyen
> Cc: linux-m...@vger.kernel.org
> Cc: openr...@lists.librecores.org
> Cc: linux-par...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: sparcli...@vger.kernel.org
> Cc: linux...@lists.infradead.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux...@kvack.org
> Suggested-by: Linus Torvalds
> Signed-off-by: Rick Edgecombe
> Link:
> https://lore.kernel.org/lkml/CAHk-=wizjsu7c9sfyzb3q04108stghff2wfbokgccgw7riz...@mail.gmail.com/
> arch/m68k/include/asm/mcf_pgtable.h | 2 +-
> arch/m68k/include/asm/motorola_pgtable.h | 2 +-
> arch/m68k/include/asm/sun3_pgtable.h | 2 +-
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
