From: Christophe Leroy <christophe.leroy@csgroup.eu> To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, npiggin@gmail.com Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 4/5] powerpc/fault: Avoid heavy search_exception_tables() verification Date: Tue, 8 Dec 2020 16:07:32 +0100 [thread overview] Message-ID: <b532a9c6-97de-031d-f880-901a117cc95c@csgroup.eu> (raw) In-Reply-To: <87lfe8qrik.fsf@linux.ibm.com> Le 08/12/2020 à 15:52, Aneesh Kumar K.V a écrit : > Christophe Leroy <christophe.leroy@csgroup.eu> writes: > >> search_exception_tables() is an heavy operation, we have to avoid it. >> When KUAP is selected, we'll know the fault has been blocked by KUAP. >> Otherwise, it behaves just as if the address was already in the TLBs >> and no fault was generated. >> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> >> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> >> --- >> v3: rebased >> v2: Squashed with the preceeding patch which was re-ordering tests that get removed in this patch. >> --- >> arch/powerpc/mm/fault.c | 23 +++++++---------------- >> 1 file changed, 7 insertions(+), 16 deletions(-) >> >> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c >> index 3fcd34c28e10..1770b41e4730 100644 >> --- a/arch/powerpc/mm/fault.c >> +++ b/arch/powerpc/mm/fault.c >> @@ -210,28 +210,19 @@ static bool bad_kernel_fault(struct pt_regs *regs, unsigned long error_code, >> return true; >> } >> >> - if (!is_exec && address < TASK_SIZE && (error_code & (DSISR_PROTFAULT | DSISR_KEYFAULT)) && >> - !search_exception_tables(regs->nip)) { >> - pr_crit_ratelimited("Kernel attempted to access user page (%lx) - exploit attempt? (uid: %d)\n", >> - address, >> - from_kuid(&init_user_ns, current_uid())); >> - } >> - >> // Kernel fault on kernel address is bad >> if (address >= TASK_SIZE) >> return true; >> >> - // Fault on user outside of certain regions (eg. copy_tofrom_user()) is bad >> - if (!search_exception_tables(regs->nip)) >> - return true; >> - >> - // Read/write fault in a valid region (the exception table search passed >> - // above), but blocked by KUAP is bad, it can never succeed. >> - if (bad_kuap_fault(regs, address, is_write)) >> + // Read/write fault blocked by KUAP is bad, it can never succeed. >> + if (bad_kuap_fault(regs, address, is_write)) { >> + pr_crit_ratelimited("Kernel attempted to %s user page (%lx) - exploit attempt? (uid: %d)\n", >> + is_write ? "write" : "read", address, >> + from_kuid(&init_user_ns, current_uid())); >> return true; >> + } > > > With this I am wondering whether the WARN() in bad_kuap_fault() is > needed. A direct access of userspace address will trigger this, whereas > previously we used bad_kuap_fault() only to identify incorrect restore > of AMR register (ie, to identify kernel bugs). Hence a WARN() there was > useful. We loose that differentiation now? Yes, I wanted to remove the WARN(), see https://patchwork.ozlabs.org/project/linuxppc-dev/patch/cc9129bdda1dbc2f0a09cf45fece7d0b0e690784.1605541983.git.christophe.leroy@csgroup.eu/ but I understood from Michael that maybe it was not a good idea, so I left it aside for now when rebasing to v3. Yes previously we were able to differentiate between a direct access of userspace and a valid access triggering a KUAP fault, but at the cost of the heavy search_exception_tables(). The issue was reported by Nick through https://github.com/linuxppc/issues/issues/317 Should be perform the search_exception_tables() once we have hit the KUAP fault and WARN() only in that case ? I was wondering also if we should keep the WARN() only when CONFIG_PPC_KUAP_DEBUG is set ? > > >> >> - // What's left? Kernel fault on user in well defined regions (extable >> - // matched), and allowed by KUAP in the faulting context. >> + // What's left? Kernel fault on user and allowed by KUAP in the faulting context. >> return false; >> } >> >> -- >> 2.25.0
WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu> To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, npiggin@gmail.com Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 4/5] powerpc/fault: Avoid heavy search_exception_tables() verification Date: Tue, 8 Dec 2020 16:07:32 +0100 [thread overview] Message-ID: <b532a9c6-97de-031d-f880-901a117cc95c@csgroup.eu> (raw) In-Reply-To: <87lfe8qrik.fsf@linux.ibm.com> Le 08/12/2020 à 15:52, Aneesh Kumar K.V a écrit : > Christophe Leroy <christophe.leroy@csgroup.eu> writes: > >> search_exception_tables() is an heavy operation, we have to avoid it. >> When KUAP is selected, we'll know the fault has been blocked by KUAP. >> Otherwise, it behaves just as if the address was already in the TLBs >> and no fault was generated. >> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> >> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> >> --- >> v3: rebased >> v2: Squashed with the preceeding patch which was re-ordering tests that get removed in this patch. >> --- >> arch/powerpc/mm/fault.c | 23 +++++++---------------- >> 1 file changed, 7 insertions(+), 16 deletions(-) >> >> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c >> index 3fcd34c28e10..1770b41e4730 100644 >> --- a/arch/powerpc/mm/fault.c >> +++ b/arch/powerpc/mm/fault.c >> @@ -210,28 +210,19 @@ static bool bad_kernel_fault(struct pt_regs *regs, unsigned long error_code, >> return true; >> } >> >> - if (!is_exec && address < TASK_SIZE && (error_code & (DSISR_PROTFAULT | DSISR_KEYFAULT)) && >> - !search_exception_tables(regs->nip)) { >> - pr_crit_ratelimited("Kernel attempted to access user page (%lx) - exploit attempt? (uid: %d)\n", >> - address, >> - from_kuid(&init_user_ns, current_uid())); >> - } >> - >> // Kernel fault on kernel address is bad >> if (address >= TASK_SIZE) >> return true; >> >> - // Fault on user outside of certain regions (eg. copy_tofrom_user()) is bad >> - if (!search_exception_tables(regs->nip)) >> - return true; >> - >> - // Read/write fault in a valid region (the exception table search passed >> - // above), but blocked by KUAP is bad, it can never succeed. >> - if (bad_kuap_fault(regs, address, is_write)) >> + // Read/write fault blocked by KUAP is bad, it can never succeed. >> + if (bad_kuap_fault(regs, address, is_write)) { >> + pr_crit_ratelimited("Kernel attempted to %s user page (%lx) - exploit attempt? (uid: %d)\n", >> + is_write ? "write" : "read", address, >> + from_kuid(&init_user_ns, current_uid())); >> return true; >> + } > > > With this I am wondering whether the WARN() in bad_kuap_fault() is > needed. A direct access of userspace address will trigger this, whereas > previously we used bad_kuap_fault() only to identify incorrect restore > of AMR register (ie, to identify kernel bugs). Hence a WARN() there was > useful. We loose that differentiation now? Yes, I wanted to remove the WARN(), see https://patchwork.ozlabs.org/project/linuxppc-dev/patch/cc9129bdda1dbc2f0a09cf45fece7d0b0e690784.1605541983.git.christophe.leroy@csgroup.eu/ but I understood from Michael that maybe it was not a good idea, so I left it aside for now when rebasing to v3. Yes previously we were able to differentiate between a direct access of userspace and a valid access triggering a KUAP fault, but at the cost of the heavy search_exception_tables(). The issue was reported by Nick through https://github.com/linuxppc/issues/issues/317 Should be perform the search_exception_tables() once we have hit the KUAP fault and WARN() only in that case ? I was wondering also if we should keep the WARN() only when CONFIG_PPC_KUAP_DEBUG is set ? > > >> >> - // What's left? Kernel fault on user in well defined regions (extable >> - // matched), and allowed by KUAP in the faulting context. >> + // What's left? Kernel fault on user and allowed by KUAP in the faulting context. >> return false; >> } >> >> -- >> 2.25.0
next prev parent reply other threads:[~2020-12-08 15:08 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-08 8:36 [PATCH v3 1/5] powerpc/book3s64/kuap: Improve error reporting with KUAP Christophe Leroy 2020-12-08 8:36 ` Christophe Leroy 2020-12-08 8:36 ` [PATCH v3 2/5] powerpc/mm: sanity_check_fault() should work for all, not only BOOK3S Christophe Leroy 2020-12-08 8:36 ` Christophe Leroy 2020-12-08 8:37 ` [PATCH v3 3/5] powerpc/fault: Unnest definition of page_fault_is_write() and page_fault_is_bad() Christophe Leroy 2020-12-08 8:37 ` Christophe Leroy 2020-12-08 8:37 ` [PATCH v3 4/5] powerpc/fault: Avoid heavy search_exception_tables() verification Christophe Leroy 2020-12-08 8:37 ` Christophe Leroy 2020-12-08 13:00 ` Aneesh Kumar K.V 2020-12-08 13:00 ` Aneesh Kumar K.V 2020-12-08 14:26 ` Christophe Leroy 2020-12-08 14:26 ` Christophe Leroy 2020-12-08 14:31 ` Aneesh Kumar K.V 2020-12-08 14:31 ` Aneesh Kumar K.V 2020-12-08 14:52 ` Aneesh Kumar K.V 2020-12-08 14:52 ` Aneesh Kumar K.V 2020-12-08 15:07 ` Christophe Leroy [this message] 2020-12-08 15:07 ` Christophe Leroy 2020-12-09 5:34 ` Christophe Leroy 2020-12-08 8:37 ` [PATCH v3 5/5] powerpc/fault: Perform exception fixup in do_page_fault() Christophe Leroy 2020-12-08 8:37 ` Christophe Leroy
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=b532a9c6-97de-031d-f880-901a117cc95c@csgroup.eu \ --to=christophe.leroy@csgroup.eu \ --cc=aneesh.kumar@linux.ibm.com \ --cc=benh@kernel.crashing.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mpe@ellerman.id.au \ --cc=npiggin@gmail.com \ --cc=paulus@samba.org \ /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: linkBe 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.