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@xxxxxxxxx/
