linux-kernel - [PATCH -tip RFC 0/2] kprobes: introduce NOKPROBE_SYMBOL() and prohibit probing on .entry.text

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131108125213.19972.49271.stgit@kbuild-fedora.novalocal>
Date:	Fri, 08 Nov 2013 12:52:13 +0000
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	x86@...nel.org, Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	lkml <linux-kernel@...r.kernel.org>,
	"Steven Rostedt (Red Hat)" <rostedt@...dmis.org>,
	virtualization@...ts.linux-foundation.org,
	"David S. Miller" <davem@...emloft.net>
Subject: [PATCH -tip RFC 0/2] kprobes: introduce NOKPROBE_SYMBOL() and
 prohibit probing on .entry.text

Currently the blacklist is maintained by hand in kprobes.c 
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've tried to implement new
NOKPROBE_SYMBOL() macro for making kprobe blacklist at 
build time. Since the NOKPROBE_SYMBOL() macros can be placed
right after the function is defined, it is easy to maintain.
At this moment, I applied the macro only for the symbols
which is listed in kprobes.c. As we discussed in previous
thread, if the gcc accepts to introduce new annotation to
store the function address (and size) at somewhere, we can
easily move onto that by replacing NOKPROBE_SYMBOL() with
nokprobe annotation (and just modifying the
populate_kprobe_blacklist() a bit).

This series also includes a change which prohibits probing
on the address in .entry.text because the code is used for
very low-level sensitive interrupt/syscall entries. Probing
such code may cause unexpected result (actually most of
that area is already in the kprobe blacklist).
So I've decide to prohibit probing all of them.

Since Ingo wasn't convinced about the idea in the previous
discussion, I just make this series as RFC series.
I'd like to ask again with actual implementation and plan.

Thank you,

---

Masami Hiramatsu (2):
      kprobes: Prohibit probing on .entry.text code
      kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist

 arch/x86/kernel/entry_32.S        |   33 ------------
 arch/x86/kernel/entry_64.S        |   20 --------
 arch/x86/kernel/paravirt.c        |    4 ++
 include/asm-generic/vmlinux.lds.h |    9 +++
 include/linux/kprobes.h           |   19 +++++++
 kernel/kprobes.c                  |   98 ++++++++++++++++++-------------------
 kernel/sched/core.c               |    1 
 7 files changed, 80 insertions(+), 104 deletions(-)

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/