From: Zorro Lang <zlang@redhat.com>
To: Nicholas Piggin <npiggin@gmail.com>, Jens Axboe <axboe@kernel.dk>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/fault: fix wrong KUAP fault for IO_URING
Date: Thu, 28 Jan 2021 11:13:56 +0800 [thread overview]
Message-ID: <20210128031355.GP14354@localhost.localdomain> (raw)
In-Reply-To: <1611792928.nw4g8h8kj4.astroid@bobo.none>
On Thu, Jan 28, 2021 at 10:18:07AM +1000, Nicholas Piggin wrote:
> Excerpts from Jens Axboe's message of January 28, 2021 5:29 am:
> > 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?
>
> Yeah the io uring code is fine, provided it uses the uaccess primitives
> like any other kernel code. It's looking more like a an arch/powerpc bug.
>
> > 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?
>
> Would be interesting to know.
Sure Nick and Jens, which 5.10 rc? version do you want to know ? Or any git
commit(be the HEAD) in 5.10 phase?
Thanks,
Zorro
>
> Thanks,
> Nick
>
next prev parent reply other threads:[~2021-01-28 2:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-27 14:56 [PATCH] powerpc/fault: fix wrong KUAP fault for IO_URING Zorro Lang
2021-01-27 16:38 ` Christophe Leroy
2021-01-27 19:29 ` Jens Axboe
2021-01-28 0:18 ` Nicholas Piggin
2021-01-28 3:13 ` Zorro Lang [this message]
2021-01-28 3:06 ` Jens Axboe
2021-01-28 13:52 ` Zorro Lang
2021-01-28 14:42 ` Jens Axboe
2021-01-28 14:44 ` Christophe Leroy
2021-01-28 15:20 ` Zorro Lang
2021-01-29 6:52 ` Zorro Lang
2021-01-29 12:26 ` Christophe Leroy
2021-01-30 11:22 ` Michael Ellerman
2021-01-30 13:54 ` Nicholas Piggin
2021-02-02 4:45 ` Aneesh Kumar K.V
2021-02-02 5:55 ` Aneesh Kumar K.V
2021-02-02 6:02 ` Christophe Leroy
2021-02-02 6:16 ` Aneesh Kumar K.V
2021-02-02 6:20 ` Christophe Leroy
2021-02-02 6:30 ` Aneesh Kumar K.V
2021-02-02 9:49 ` Nicholas Piggin
2021-02-04 16:53 ` Jens Axboe
2021-02-04 17:01 ` Aneesh Kumar K.V
2021-02-04 17:03 ` Jens Axboe
2021-02-04 17:57 ` Zorro Lang
2021-02-04 17:42 ` Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210128031355.GP14354@localhost.localdomain \
--to=zlang@redhat.com \
--cc=axboe@kernel.dk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.