On Wed, Oct 20, 2021 at 10:11:19AM -1000, Linus Torvalds wrote: > On Wed, Oct 20, 2021 at 6:37 AM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > The atomic "add zero" trick isn't that simple for MTE since the arm64 > > atomic or exclusive instructions run with kernel privileges and > > therefore with the kernel tag checking mode. > > Are there any instructions that are useful for "probe_user_write()" > kind of thing? If it's on a user address, the only single-instruction that works with MTE is STTR (as in put_user()) but that's destructive. Other "add zero" constructs require some potentially expensive system register accesses just to set the tag checking mode of the current task. A probe_user_write() on the kernel linear address involves reading the tag from memory and comparing it with the tag in the user pointer. In addition, it needs to take into account the current task's tag checking mode and the vma vm_flags. We should have most of the information in the gup code. > Although at least for MTE, I think the solution was to do a regular > read, and that checks the tag, and then we could use the gup machinery > for the writability checks. Yes, for MTE this should work. For CHERI I think an "add zero" would do the trick (it should have atomics that work on capabilities directly). However, with MTE doing both get_user() every 16 bytes and gup can get pretty expensive. The problematic code is fault_in_safe_writable() in this series. I can give this 16-byte probing in gup a try (on top of -next) but IMHO we unnecessarily overload the fault_in_*() logic with something the kernel cannot fix up. The only reason we do it is so that we get an error code and bail out of a loop but the uaccess routines could be extended to report the fault type instead. It looks like we pretty much duplicate the uaccess in the fault_in_*() functions (four accesses per cache line). -- Catalin
