On 1/27/21 9:38 AM, Christophe Leroy wrote: > > > Le 27/01/2021 à 15:56, Zorro Lang a écrit : >> On powerpc, io_uring test hit below KUAP fault on __do_page_fault. >> The fail source line is: >> >> if (unlikely(!is_user && bad_kernel_fault(regs, error_code, address, >> is_write))) >> return SIGSEGV; >> >> The is_user() is based on user_mod(regs) only. This's not suit for >> io_uring, where the helper thread can assume the user app identity >> and could perform this fault just fine. So turn to use mm to decide >> if this is valid or not. > > I don't understand why testing is_user would be an issue. KUAP purpose > it to block any unallowed access from kernel to user memory > (Equivalent to SMAP on x86). So it really must be based on MSR_PR bit, > that is what is_user provides. > > If the kernel access is legitimate, kernel should have opened > userspace access then you shouldn't get this "Bug: Read fault blocked > by KUAP!". > > As far as I understand, the fault occurs in > iov_iter_fault_in_readable() which calls fault_in_pages_readable() And > fault_in_pages_readable() uses __get_user() so it is a legitimate > access and you really should get a KUAP fault. > > So the problem is somewhere else, I think you proposed patch just > hides the problem, it doesn't fix it.
If we do kthread_use_mm(), can we agree that the user access is valid? We should be able to copy to/from user space, and including faults, if that's been done and the new mm assigned. Because it really should be. If SMAP was a problem on x86, we would have seen it long ago. I'm assuming this may be breakage related to the recent uaccess changes related to set_fs and friends? Or maybe recent changes on the powerpc side? Zorro, did 5.10 work? -- Jens Axboe
