Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754603AbbHDX3V (ORCPT ); Tue, 4 Aug 2015 19:29:21 -0400 Received: from mail9.hitachi.co.jp ([133.145.228.44]:45174 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754567AbbHDX3T convert rfc822-to-8bit (ORCPT ); Tue, 4 Aug 2015 19:29:19 -0400 From: =?iso-2022-jp?B?GyRCSj8+PjJtTCYbKEIgLyBISVJBTUFUVRskQiEkGyhCTUFTQU1J?= To: "'Frederic Weisbecker'" , Andy Lutomirski CC: Peter Zijlstra , "linux-kernel@vger.kernel.org" , Brian Gerst , "Steven Rostedt" , Borislav Petkov , "Thomas Gleixner" , Linus Torvalds , X86 ML Subject: RE: [PATCH 1/3] x86/perf/hw_breakpoint: Disallow kernel breakpoints unless kprobe-safe Thread-Topic: [PATCH 1/3] x86/perf/hw_breakpoint: Disallow kernel breakpoints unless kprobe-safe Thread-Index: AQHQy0GSiCHjIGZSfkyuuW3N9eJREJ37bZuAgAET43A= Date: Tue, 4 Aug 2015 23:29:14 +0000 Message-ID: <50399556C9727B4D88A595C8584AAB375249C089@GSjpTKYDCembx32.service.hitachi.net> References: <20150804155158.GB32738@lerouge> In-Reply-To: <20150804155158.GB32738@lerouge> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.219.34] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3201 Lines: 87 Hi, > From: Frederic Weisbecker [mailto:fweisbec@gmail.com] > > On Thu, Jul 30, 2015 at 08:32:40PM -0700, Andy Lutomirski wrote: > > Code on the kprobe blacklist doesn't want unexpected int3 > > exceptions. It probably doesn't want unexpected debug exceptions > > either. Be safe: disallow breakpoints in nokprobes code. > > > > On non-CONFIG_KPROBES kernels, there is no kprobe blacklist. In > > that case, disallow kernel breakpoints entirely. > > > > It will be particularly important to keep hw breakpoints out of the > > entry and NMI code once we move debug exceptions off the IST stack. > > > > Signed-off-by: Andy Lutomirski > > --- > > arch/x86/kernel/hw_breakpoint.c | 15 +++++++++++++++ > > include/linux/kprobes.h | 2 ++ > > kernel/kprobes.c | 2 +- > > 3 files changed, 18 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c > > index 7114ba220fd4..78f3e90c5659 100644 > > --- a/arch/x86/kernel/hw_breakpoint.c > > +++ b/arch/x86/kernel/hw_breakpoint.c > > @@ -32,6 +32,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -243,6 +244,20 @@ static int arch_build_bp_info(struct perf_event *bp) > > info->type = X86_BREAKPOINT_RW; > > break; > > case HW_BREAKPOINT_X: > > + /* > > + * We don't allow kernel breakpoints in places that are not > > + * acceptable for kprobes. On non-kprobes kernels, we don't > > + * allow kernel breakpoints at all. > > + */ > > + if (bp->attr.bp_addr >= TASK_SIZE_MAX) { > > +#ifdef CONFIG_KPROBES > > + if (within_kprobe_blacklist(bp->attr.bp_addr)) > > + return -EINVAL; > > +#else > > + return -EINVAL; > > +#endif > > + } > > + > > It should be done on generic code I think. In validate_hw_breakpoint() > under the arch_check_bp_in_kernelspace() check. Agreed, kprobes also does it in generic code. > > > info->type = X86_BREAKPOINT_EXECUTE; > > /* > > * x86 inst breakpoints need to have a specific undefined len. > > diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h > > index 1ab54754a86d..8f6849084248 100644 > > --- a/include/linux/kprobes.h > > +++ b/include/linux/kprobes.h > > @@ -267,6 +267,8 @@ extern void show_registers(struct pt_regs *regs); > > extern void kprobes_inc_nmissed_count(struct kprobe *p); > > extern bool arch_within_kprobe_blacklist(unsigned long addr); > > > > +extern bool within_kprobe_blacklist(unsigned long addr); > > The name was fine for a kprobe's private function. But if you make > it public, maybe standardize the prefix like kprobes_within_blacklist(). No, there is the "kprobe_blacklist", that function means "whether the address is within kprobe_blacklist or not?" like within_module_core. Thank you, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/