Re: [PATCH v15 2/4] syscall user dispatch: untag selector addresses before access_ok

[Catalin Marinas <catalin.marinas@arm.com>]

On Tue, Apr 04, 2023 at 06:33:40PM +0100, Catalin Marinas wrote:
> On Tue, Apr 04, 2023 at 12:45:06PM +0200, Oleg Nesterov wrote:
> > doesn't this mean that access_ok() on arm64 could use
> > untagged_addr(addr) unconditionally without any security risk?
> 
> Yes, from the security perspective, but there are ABI implications.
> 
> Currently untagged_addr() in access_ok() is conditional on the user
> process enabling the tagged address ABI (prctl() that sets a TIF flag).
> The reason we did not enable this by default was a slight fear of
> breaking the ABI since tagged pointers were not allowed at the syscall
> boundary. It turned out that the fear was justified since the
> unconditional untagged_addr() in brk() broke user space (see commit
> dcde237319e6 "mm: Avoid creating virtual address aliases in
> brk()/mmap()/mremap()"; the user was doing an sbrk(PY_SSIZE_T_MAX) and
> bits 56 and higher were ignored by the kernel).
> 
> I'd be ok with untagging the address unconditionally in the arm64
> access_ok() introduce another unaliased_access_ok() (I'm not good at
> naming functions) that preserves the non-tagged behaviour and we use it
> in brk/mmap/mremap().

Actually, I'm wrong here. There's no access_ok() check on the brk()
path. The unconditional untagged_addr() prior to dcde237319e6 messed up
the comparison between the old and new brk limit and shrank the heap
space for a process.

So, relaxing access_ok() to always do the untagging should not affect
the brk/mmap/mremap() cases.

-- 
Catalin