RE: [RFC PATCH v0 3/6] x86: Enable Upper Address Ignore(UAI) feature

[David Laight <David.Laight@ACULAB.COM>]

From: Andrew Cooper
> Sent: 10 March 2022 19:47
> 
> On 10/03/2022 11:15, Bharata B Rao wrote:
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index f7a132eb794d..12615b1b4af5 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -740,6 +740,12 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
> >  	return 0;
> >  }
> >
> > +static inline void __init uai_enable(void)
> > +{
> > +	if (boot_cpu_has(X86_FEATURE_UAI))
> > +		msr_set_bit(MSR_EFER, _EFER_UAI);
> > +}
> > +
> >  /*
> >   * Determine if we were loaded by an EFI loader.  If so, then we have also been
> >   * passed the efi memmap, systab, etc., so we should use these data structures
> > @@ -1146,6 +1152,8 @@ void __init setup_arch(char **cmdline_p)
> >
> >  	x86_init.paging.pagetable_init();
> >
> > +	uai_enable();
> 
> I would think incredibly carefully before enabling UAI by default.
> 
> Suffice it to say that Intel were talked down from 7 bits to 6, and
> apparently AMD didn't get the same memo from the original requesters.
> 
> The problem is that UAI + LA57 means that all the poison pointers cease
> functioning as a defence-in-depth mechanism, and become legal pointers
> pointing at random positions in user or kernel space.

Isn't that true regardless of how many bits are 'ignored'.
AFAICT the only sane thing would be to have something in the cpu
that verifies the 'ignored' bits match values set in the PTE.
That could be used to ensure (well make it more likely) that stack
access stay in the stack and pointers to mmap()ed data stay
pointing to the correct pages.

Just letting user address space be aliased a lot of times doesn't
seem like a security feature to me.
It must have some strange use case.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)