From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751285AbdBXRtc (ORCPT ); Fri, 24 Feb 2017 12:49:32 -0500 Received: from merlin.infradead.org ([205.233.59.134]:59078 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751208AbdBXRt2 (ORCPT ); Fri, 24 Feb 2017 12:49:28 -0500 Date: Fri, 24 Feb 2017 18:48:27 +0100 From: Peter Zijlstra To: Masami Hiramatsu Cc: Borislav Petkov , linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner Subject: Re: kprobes vs __ex_table[] Message-ID: <20170224174827.GS6500@twins.programming.kicks-ass.net> References: <20170223183002.GD6557@twins.programming.kicks-ass.net> <20170224100451.31ca3855ddb36963b93d0768@kernel.org> <20170224092646.GL6515@twins.programming.kicks-ass.net> <20170225013415.1a197937e4e743143359c5b0@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170225013415.1a197937e4e743143359c5b0@kernel.org> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 25, 2017 at 01:34:15AM +0900, Masami Hiramatsu wrote: > > Ah, but that is only #PF, we also use __ex_table on other faults/traps, > > like #GP which would need help in do_general_protection(), > > #GP is also handled via kprobe_exceptions_notify(). Ah! that's where its hidden :-) Thanks! > > It looks like it rewrites regs->ip, which would make return from fault > > return to the wrong place, no? > > Hmm, when regs->ip is reset to the original place, kprobe_fault_handler() > returns 0 and normal #PF handler fixup pages etc. and retry from the > original place. This might kick kprobes again and do singlestep. > > So, yes, it may not enough for other faults if those will not only check > regs->ip, but read the instruction pointed by regs->ip (as your patch). > In that case you need to use recover_probed_instruction() instead of > probe_kernel_address(). (BTW, recover_probed_instruction() uses memcpy() > without checking kernel_text, it should use probe_kernel_address().) > > One more complication with __ex_table and optimized kprobes is that we > > need to be careful not to clobber __ex_table[].fixup. It would be very > > bad if the optimized probe were to clobber the address we let the fixup > > return to -- or that needs fixups too, _after_ running > > __ex_table[].handler(). > > can_optimize() takes care about that case. If the probe target function > (not only probed address) includes an exception address, it rejects > optimizing probes. Ah, so it does search_exception_tables(), which avoids clobbering actual exception instructions, and most fixups live in .text.fixup and I cannot actually find if that is excluded. In any case, thanks for the pointers, I'll see if I can spot any actual holes.