On Thu, Jul 01, 2021 at 10:27:31PM -0700, Lokesh Gidra wrote: > On Thu, Jul 1, 2021 at 10:50 AM Peter Collingbourne <pcc@xxxxxxxxxx> wrote: > > On Thu, Jul 1, 2021 at 8:51 AM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > > On Wed, Jun 30, 2021 at 04:29:31PM -0700, Peter Collingbourne wrote: > > > > If a user program uses userfaultfd on ranges of heap memory, it may > > > > end up passing a tagged pointer to the kernel in the range.start > > > > field of the UFFDIO_REGISTER ioctl. This can happen when using an > > > > MTE-capable allocator, or on Android if using the Tagged Pointers > > > > feature for MTE readiness [1]. > > > > > > When we added the tagged addr ABI, we realised it's nearly impossible to > > > sort out all ioctls, so we added a note to the documentation that any > > > address other than pointer to user structures as arguments to ioctl() > > > should be untagged. Arguably, userfaultfd is not a random device but if > > > we place it in the same category as mmap/mremap/brk, those don't allow > > > tagged pointers either. And we do expect some apps to break when they > > > rely on malloc() to return untagged pointers. > > > > Okay, so arguably another approach would be to make userfaultfd > > consistent with mmap/mremap/brk and let the UFFDIO_REGISTER fail if > > given a tagged address. > > This approach also seems reasonable. The problem, as things stand > today, is that UFFDIO_REGISTER doesn't complain when a tagged pointer > is used to register a memory range. But eventually the returned fault > address in messages are untagged. If UFFDIO_REGISTER were to fail on > passing a tagged pointer, then the userspace can address the issue. On the mmap etc. functions we get an error as a side effect of addr being larger than TASK_SIZE (unless explicitly untagged). The userfaultfd_register() function had similar checks but they were relaxed by commit 7d0325749a6c ("userfaultfd: untag user pointers"). I think we should revert the above, or part of it. We did something similar for mmap/mremap/brk when untagging the address broke glibc: commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"). -- Catalin