| Message ID | 20230822-arm64-gcs-v5-11-9ef181dd6324@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm64/gcs: Provide support for GCS in userspace | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/tree_selection | fail | Failed to apply to next/pending-fixes, riscv/for-next or riscv/master |
On 22.08.23 15:56, Mark Brown wrote: > Use VM_HIGH_ARCH_5 for guarded control stack pages. > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > Documentation/filesystems/proc.rst | 2 +- > fs/proc/task_mmu.c | 3 +++ > include/linux/mm.h | 12 +++++++++++- > 3 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst > index 6ccb57089a06..086a0408a4d7 100644 > --- a/Documentation/filesystems/proc.rst > +++ b/Documentation/filesystems/proc.rst > @@ -566,7 +566,7 @@ encoded manner. The codes are the following: > mt arm64 MTE allocation tags are enabled > um userfaultfd missing tracking > uw userfaultfd wr-protect tracking > - ss shadow stack page > + ss shadow/guarded control stack page > == ======================================= > > Note that there is no guarantee that every flag and associated mnemonic will > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index cfab855fe7e9..e8c50848bb16 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -711,6 +711,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) > #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */ > #ifdef CONFIG_X86_USER_SHADOW_STACK > [ilog2(VM_SHADOW_STACK)] = "ss", > +#endif > +#ifdef CONFIG_ARM64_GCS > + [ilog2(VM_SHADOW_STACK)] = "ss", > #endif See my comment below. > }; > size_t i; > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 43fe625b85aa..3f939ae212e5 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -372,7 +372,17 @@ extern unsigned int kobjsize(const void *objp); > * having a PAGE_SIZE guard gap. > */ > # define VM_SHADOW_STACK VM_HIGH_ARCH_5 > -#else > +#endif > + > +#if defined(CONFIG_ARM64_GCS) > +/* > + * arm64's Guarded Control Stack implements similar functionality and > + * has similar constraints to shadow stacks. > + */ > +# define VM_SHADOW_STACK VM_HIGH_ARCH_5 > +#endif Shouldn't that all just merged with the previous define(s)? Also, I wonder if we now want to have CONFIG_HAVE_ARCH_SHADOW_STACK or similar.
On Tue, Aug 22, 2023 at 05:21:09PM +0200, David Hildenbrand wrote: > On 22.08.23 15:56, Mark Brown wrote: > > @@ -372,7 +372,17 @@ extern unsigned int kobjsize(const void *objp); > > * having a PAGE_SIZE guard gap. > > */ > > # define VM_SHADOW_STACK VM_HIGH_ARCH_5 > > -#else > > +#endif > > + > > +#if defined(CONFIG_ARM64_GCS) > > +/* > > + * arm64's Guarded Control Stack implements similar functionality and > > + * has similar constraints to shadow stacks. > > + */ > > +# define VM_SHADOW_STACK VM_HIGH_ARCH_5 > > +#endif > Shouldn't that all just merged with the previous define(s)? > Also, I wonder if we now want to have CONFIG_HAVE_ARCH_SHADOW_STACK or > similar. I can certainly update it to do that, I was just trying to fit in with how the code was written on the basis that there was probably a good reason for it that had been discussed somewhere. I can send an incremental patch for this on top of the x86 patches assuming they go in during the merge window.
On Tue, 2023-08-22 at 16:41 +0100, Mark Brown wrote: > On Tue, Aug 22, 2023 at 05:21:09PM +0200, David Hildenbrand wrote: > > On 22.08.23 15:56, Mark Brown wrote: > > > > @@ -372,7 +372,17 @@ extern unsigned int kobjsize(const void > > > *objp); > > > * having a PAGE_SIZE guard gap. > > > */ > > > # define VM_SHADOW_STACK VM_HIGH_ARCH_5 > > > -#else > > > +#endif > > > + > > > +#if defined(CONFIG_ARM64_GCS) > > > +/* > > > + * arm64's Guarded Control Stack implements similar > > > functionality and > > > + * has similar constraints to shadow stacks. > > > + */ > > > +# define VM_SHADOW_STACK VM_HIGH_ARCH_5 > > > +#endif > > > Shouldn't that all just merged with the previous define(s)? > > > Also, I wonder if we now want to have CONFIG_HAVE_ARCH_SHADOW_STACK > > or > > similar. > > I can certainly update it to do that, I was just trying to fit in > with > how the code was written on the basis that there was probably a good > reason for it that had been discussed somewhere. I can send an > incremental patch for this on top of the x86 patches assuming they go > in > during the merge window. There was something like that on the x86 series way back, but it was dropped[0]. IIRC risc-v was going to try to do something other than VM_SHADOW_STACK, so they may conflict some day. But in the meantime, adding a CONFIG_HAVE_ARCH_SHADOW_STACK here in the arm series makes sense to me. [0] https://lore.kernel.org/lkml/d09e952d8ae696f687f0787dfeb7be7699c02913.camel@intel.com/
On Tue, Aug 22, 2023 at 04:47:26PM +0000, Edgecombe, Rick P wrote: > On Tue, 2023-08-22 at 16:41 +0100, Mark Brown wrote: > > I can certainly update it to do that, I was just trying to fit in > > with > > how the code was written on the basis that there was probably a good > > reason for it that had been discussed somewhere. I can send an > > incremental patch for this on top of the x86 patches assuming they go > > in > > during the merge window. > There was something like that on the x86 series way back, but it was > dropped[0]. IIRC risc-v was going to try to do something other than > VM_SHADOW_STACK, so they may conflict some day. But in the meantime, > adding a CONFIG_HAVE_ARCH_SHADOW_STACK here in the arm series makes > sense to me. OK, I'll do that.
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 6ccb57089a06..086a0408a4d7 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -566,7 +566,7 @@ encoded manner. The codes are the following: mt arm64 MTE allocation tags are enabled um userfaultfd missing tracking uw userfaultfd wr-protect tracking - ss shadow stack page + ss shadow/guarded control stack page == ======================================= Note that there is no guarantee that every flag and associated mnemonic will diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index cfab855fe7e9..e8c50848bb16 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -711,6 +711,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */ #ifdef CONFIG_X86_USER_SHADOW_STACK [ilog2(VM_SHADOW_STACK)] = "ss", +#endif +#ifdef CONFIG_ARM64_GCS + [ilog2(VM_SHADOW_STACK)] = "ss", #endif }; size_t i; diff --git a/include/linux/mm.h b/include/linux/mm.h index 43fe625b85aa..3f939ae212e5 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -372,7 +372,17 @@ extern unsigned int kobjsize(const void *objp); * having a PAGE_SIZE guard gap. */ # define VM_SHADOW_STACK VM_HIGH_ARCH_5 -#else +#endif + +#if defined(CONFIG_ARM64_GCS) +/* + * arm64's Guarded Control Stack implements similar functionality and + * has similar constraints to shadow stacks. + */ +# define VM_SHADOW_STACK VM_HIGH_ARCH_5 +#endif + +#ifndef VM_SHADOW_STACK # define VM_SHADOW_STACK VM_NONE #endif
Use VM_HIGH_ARCH_5 for guarded control stack pages. Signed-off-by: Mark Brown <broonie@kernel.org> --- Documentation/filesystems/proc.rst | 2 +- fs/proc/task_mmu.c | 3 +++ include/linux/mm.h | 12 +++++++++++- 3 files changed, 15 insertions(+), 2 deletions(-)