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
