Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753993AbbHOQzm (ORCPT ); Sat, 15 Aug 2015 12:55:42 -0400 Received: from mail-io0-f179.google.com ([209.85.223.179]:32999 "EHLO mail-io0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751408AbbHOQzl (ORCPT ); Sat, 15 Aug 2015 12:55:41 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 15 Aug 2015 18:55:40 +0200 Message-ID: Subject: Re: More hw_breakpoint scariness reduction From: Frederic Weisbecker To: Andy Lutomirski Cc: Peter Zijlstra , Linus Torvalds , X86 ML , "linux-kernel@vger.kernel.org" , Sasha Levin , Masami Hiramatsu Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1127 Lines: 22 2015-08-15 0:38 GMT+02:00 Andy Lutomirski : > Would you all consider it acceptable to disallow watchpoints on per > cpu data entirely? I can think of a *lot* of places where hitting #DB > when accessing per cpu data from entry asm would be bad. > > Of course, actually implementing that might be less than entirely fun, > given that a cpu could be onlined after creating a watchpoint. Well I think there will always be places where setting a breakpoint is a bad idea. The same goes for kprobes. We can't fix all of them. Kernel breakpoints can only be set by root users so it's not a security issue. Besides, kernel breakpoints should only be used by kernel hackers (perf, kdb). Given the wide use of per-cpu data, forbidding all of them will seriously reduce the usability of kernel breakpoints. Not that I think they are really used in practice though ;-) -- 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/