lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 20 Jun 2019 16:19:17 +0900 From: Masami Hiramatsu <mhiramat@...nel.org> To: Vineet Gupta <Vineet.Gupta1@...opsys.com> Cc: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>, Anshuman Khandual <anshuman.khandual@....com>, Fenghua Yu <fenghua.yu@...el.com>, arcml <linux-snps-arc@...ts.infradead.org>, "Masami Hiramatsu" <mhiramat@...nel.org> Subject: Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault() Hi, On Tue, 18 Jun 2019 08:56:33 -0700 Vineet Gupta <Vineet.Gupta1@...opsys.com> wrote: > +CC Masami San, Eugeniy > > On 6/13/19 10:57 AM, Vineet Gupta wrote: > > > > On 6/13/19 3:07 AM, Anshuman Khandual wrote: > >> Questions: > >> > >> AFAICT there is no equivalent of erstwhile notify_page_fault() during page > >> fault handling in arc and mips archs which can call this generic function. > >> Please let me know if that is not the case. > > > > For ARC do_page_fault() is entered for MMU exceptions (TLB Miss, access violations > > r/w/x etc). kprobes uses a combination of UNIMP_S and TRAP_S instructions which > > don't funnel into do_page_fault(). > > > > UINMP_S leads to > > > > instr_service > > do_insterror_or_kprobe > > notify_die(DIE_IERR) > > kprobe_exceptions_notify > > arc_kprobe_handler > > > > > > TRAP_S 2 leads to > > > > EV_Trap > > do_non_swi_trap > > trap_is_kprobe > > notify_die(DIE_TRAP) > > kprobe_exceptions_notify > > arc_post_kprobe_handler > > > > But indeed we are *not* calling into kprobe_fault_handler() - from eithet of those > > paths and not sure if the existing arc*_kprobe_handler() combination does the > > equivalent in tandem. Interesting, it seems that the kprobe_fault_handler() has never been called. Anyway, it is used for handling a page fault in kprobe's user handler or single stepping. And a page fault in user handler will not hard to fix up. Only a hard case is a page fault in single stepping. If ARC's kprobes using single-stepping on copied buffer, it may crashes kernel, since fixup code can not find correct address without kprobe_fault_handler. Thank you, > > @Eugeniy can you please investigate this - do we have krpobes bit rot in ARC port. > > -Vineet > > -- Masami Hiramatsu <mhiramat@...nel.org>
Powered by blists - more mailing lists