On Fri, Mar 17, 2023 at 10:16 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>
> On 3/17/23 10:12, Deepak Gupta wrote:
> >> /*
> >> - * Stack area - automatically grows in one direction
> >> + * Stack area
> >> *
> >> - * VM_GROWSUP / VM_GROWSDOWN VMAs are always private anonymous:
> >> - * do_mmap() forbids all other combinations.
> >> + * VM_GROWSUP, VM_GROWSDOWN VMAs are always private
> >> + * anonymous. do_mmap() forbids all other combinations.
> >> */
> >> static inline bool is_stack_mapping(vm_flags_t flags)
> >> {
> >> - return (flags & VM_STACK) == VM_STACK;
> >> + return ((flags & VM_STACK) == VM_STACK) || (flags & VM_SHADOW_STACK);
> > Same comment here. `VM_SHADOW_STACK` is an x86 specific way of
> > encoding a shadow stack.
> > Instead let's have a proxy here which allows architectures to have
> > their own encodings to represent a shadow stack.
>
> This doesn't _preclude_ another architecture from coming along and doing
> that, right? I'd just prefer that shadow stack architecture #2 comes
> along and refactors this in precisely the way _they_ need it.
There are two issues here
- Encoding of shadow stack: Another arch can choose different encoding.
And yes, another architecture can come in and re-factor it. But so
much thought and work has been given to x86 implementation to keep
shadow stack to not impact arch agnostic parts of the kernel. So
why creep it in here.
- VM_SHADOW_STACK is coming out of the VM_HIGH_ARCH_XX bit position
which makes it arch specific.
If re-factor takes care then I would say the 2nd issue still exists,
it's better to keep it away from arch agnostic code.
