From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: "平松雅巳 / HIRAMATU,MASAMI" <masami.hiramatsu.pt@hitachi.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"ming.lei@canonical.com" <ming.lei@canonical.com>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"x86@kernel.org" <x86@kernel.org>,
"anil.s.keshavamurthy@intel.com" <anil.s.keshavamurthy@intel.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
"jbaron@akamai.com" <jbaron@akamai.com>,
"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>
Subject: Re: [Xen-devel] [RFC v2 7/7] kprobes: port to linker table
Date: Fri, 22 Jul 2016 01:53:36 +0200 [thread overview]
Message-ID: <20160721235336.GB5537@wotan.suse.de> (raw)
In-Reply-To: <20160223005244.GE25240@wotan.suse.de>
On Tue, Feb 23, 2016 at 01:52:44AM +0100, Luis R. Rodriguez wrote:
> On Mon, Feb 22, 2016 at 01:34:05AM +0000, 平松雅巳 / HIRAMATU,MASAMI wrote:
> > >From: Luis R. Rodriguez [mailto:mcgrof@kernel.org]
> > >
> > >kprobe makes use of two custom sections:
> > >
> > >type name begin end
> > >init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist
> > >text .kprobes.text __kprobes_text_start __kprobes_text_end
> > >
> > >Port these to the linker table generic solution. This lets
> > >us remove all the custom kprobe section declarations on the
> > >linker script.
> > >
> > >Tested with CONFIG_KPROBES_SANITY_TEST, it passes with:
> > >
> > >Kprobe smoke test: started
> > >Kprobe smoke test: passed successfully
> > >
> > >Then tested CONFIG_SAMPLE_KPROBES on do_fork, and the
> > >kprobe bites and kicks as expected. Lastly tried registering
> > >a kprobe on a kprobe blacklisted symbol (NOKPROBE_SYMBOL()),
> > >and confirms that fails to work.
> >
> > Could you also check to run the testcases by using ftracetest as below?
> >
> > $ cd tools/testing/selftests/ftrace/
> > $ sudo ./ftracetest
>
> Sure, it all passed:
>
> $ sudo ./ftracetest
> === Ftrace unit tests ===
> [1] Basic trace file check [PASS]
> [2] Basic test for tracers [PASS]
> [3] Basic trace clock test [PASS]
> [4] Basic event tracing check [PASS]
> [5] event tracing - enable/disable with event level files [PASS]
> [6] event tracing - enable/disable with subsystem level files [PASS]
> [7] event tracing - enable/disable with top level files [PASS]
> [8] ftrace - function graph filters with stack tracer [PASS]
> [9] ftrace - function graph filters [PASS]
> [10] ftrace - function profiler with function tracing [PASS]
> [11] Test creation and deletion of trace instances [PASS]
> [12] Kprobe dynamic event - adding and removing [PASS]
> [13] Kprobe dynamic event - busy event check [PASS]
> [14] Kprobe dynamic event with arguments [PASS]
> [15] Kprobe dynamic event with function tracer [PASS]
> [16] Kretprobe dynamic event with arguments [PASS]
>
> # of passed: 16
> # of failed: 0
> # of unresolved: 0
> # of untested: 0
> # of unsupported: 0
> # of xfailed: 0
> # of undefined(test bug): 0
The number of tests have grown, this still passes in the new rebase.
> > And I'm not sure about linker table.
>
> So there's really a few parts to the linker table work, out of
> the ones that relate to kprobes:
>
> * linker tables try to generalize our section use, and provide some
> helpers for common section use
> * provides helpers to make it easier to make custom section,
> but by re-using standard sections
> * when a custom section uses standard sections and helpers
> we also get a few gains:
> - developers reviewing code can more easily get a quicker
> understanding and have expectations set of how the code
> feature using the custom section could be used
> - people grep'ing on the kernel can more easily find
> specific types of custom section use by looking for
> the type of interest
> - developers adding features do not need to modify
> any linker scripts (vmlinux.lds.S) to make use of
> custom sections
>
> In kprobe's case, since it uses two custom sections, we have
> only a small use for the first case: .kprobe.text is just used
> as a place holder for future developer annotated special cased
> executable code. It also makes use of the generic helpers:
> LINKTABLE_ADDR_WITHIN(), LINKTABLE_START(), LINKTABLE_END().
>
> The second use case, for the _kprobe_blacklist, makes much more
> use of the more advanced linker table helpers, for instance the
> iterator LINKTABLE_FOR_EACH().
>
> For both though we now have each custom section's actual section
> clearly highlighted:
>
> * kprobes: .text (SECTION_TEXT)
> * kprobe blacklist: init.data (SECTION_INIT_DATA)
I ended up splitting this in two patches, in the new v3 series
kprobes will go under a simple section range, while the blacklist
stuff gets its linker table.
> A reader / developer can more easily gain an understanding
> of how the above custom sections could be used just by its
> type.
>
> Another feature of linker tables, but outside of the scope of how kprobe
> would use linker tables, is the ability to enable folks to avoid code
> bit rot by using table-$(CONFIG_FOO) instead of oby-$(CONFIG_FOO) on
> init paths of code but since this is outside of the scope of how kprobe would
> use I leave that just as a reference as another part of linker table.
> Unless of course you want to make people force compile all kprobe
> support code but only have it linked in when actually enabled. That
> would be outside of the scope and purpose of this patch though.
>
> > Is that possible to support
> > __kprobes prefix, which moves the functions into kprobes.text?
>
> Absolutely, the respective change was just to annotate and make
> it clear the section kprobes were using:
>
> -# define __kprobes __attribute__((__section__(".kprobes.text")))
> +#include <linux/sections.h>
> +# define __kprobes __attribute__((__section__(SECTION_TBL(SECTION_TEXT, kprobes, all))))
>
> > Actually, I'm on the way to replacing __kprobes to NOKPROBE_SYMBOL
> > macro, since NOKPROBE_SYMBOL() doesn't effect the kernel text itself.
> > On x86, it is already replaced (see commit 820aede0209a), and same
> > work should be done on other archs. So, could you hold this after
> > that?
>
> Sure.
>
> > I think we should remove .kprobes.text first
>
> You mean just remove the incorrect users of .kprobes.text because as I read
> what you described above we have abuse of __kprobes use to protect against
> kprobes being introduced on those routines, and we should be using
> NOKPROBE_SYMBOL() instead. So from what I gather its not that you will
> remove .kprobes.text but rather clean our current abuse of __kprobes
> for protection to use NOKPROBE_SYMBOL() instead. Is that right?
I never heard back :(
> > and move to linker table.
>
> Sure, can you Cc me on your patches? I can follow up later.
And I was never Cc'd on these patches so its unclear if this work
is done. I'll be posting a v3 series now.
Luis
next prev parent reply other threads:[~2016-07-21 23:53 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 13:45 [RFC v2 0/7] linux: add linker tables Luis R. Rodriguez
2016-02-19 13:45 ` [RFC v2 1/7] sections.h: add sections header to collect all section info Luis R. Rodriguez
2016-02-19 16:23 ` Greg KH
2016-02-19 20:06 ` Luis R. Rodriguez
2016-02-19 21:25 ` Greg KH
2016-02-19 21:59 ` Luis R. Rodriguez
2016-02-19 13:45 ` [RFC v2 2/7] tables.h: add linker table support Luis R. Rodriguez
2016-02-19 20:25 ` H. Peter Anvin
2016-02-19 21:48 ` Luis R. Rodriguez
2016-02-23 23:08 ` Luis R. Rodriguez
2016-02-23 23:22 ` H. Peter Anvin
2016-02-23 23:36 ` Luis R. Rodriguez
2016-02-24 0:06 ` H. Peter Anvin
2016-02-24 0:54 ` Luis R. Rodriguez
2016-02-19 20:33 ` H. Peter Anvin
2016-02-19 21:12 ` Luis R. Rodriguez
2016-02-19 13:45 ` [RFC v2 3/7] firmware: port built-in section to linker table Luis R. Rodriguez
2016-02-29 10:12 ` David Woodhouse
2016-02-29 18:56 ` Luis R. Rodriguez
2016-05-02 18:34 ` Kees Cook
2016-05-02 18:41 ` Greg KH
2016-05-03 17:08 ` Luis R. Rodriguez
2016-05-03 17:07 ` Luis R. Rodriguez
2016-05-03 17:10 ` Luis R. Rodriguez
2016-05-03 17:11 ` Luis R. Rodriguez
2016-05-03 17:21 ` Kees Cook
2016-05-03 18:12 ` Greg KH
2016-03-01 16:10 ` James Bottomley
2016-03-01 17:54 ` Luis R. Rodriguez
2016-04-29 19:24 ` Luis R. Rodriguez
2016-02-19 13:45 ` [RFC v2 4/7] asm/sections: add a generic push_section_tbl() Luis R. Rodriguez
2016-02-19 20:26 ` H. Peter Anvin
2016-02-19 21:06 ` Luis R. Rodriguez
2016-02-22 2:55 ` H. Peter Anvin
2016-02-26 14:56 ` Heiko Carstens
2016-05-20 19:53 ` Luis R. Rodriguez
2016-02-19 13:45 ` [RFC v2 5/7] jump_label: port __jump_table to linker tables Luis R. Rodriguez
2016-02-19 13:45 ` [RFC v2 6/7] dynamic_debug: port to use " Luis R. Rodriguez
2016-02-19 13:45 ` [RFC v2 7/7] kprobes: port to linker table Luis R. Rodriguez
2016-02-19 14:15 ` Russell King - ARM Linux
2016-02-19 14:55 ` Luis R. Rodriguez
2016-02-22 1:34 ` 平松雅巳 / HIRAMATU,MASAMI
2016-02-23 0:52 ` [Xen-devel] " Luis R. Rodriguez
2016-07-21 23:53 ` Luis R. Rodriguez [this message]
2016-02-19 20:16 ` [RFC v2 0/7] linux: add linker tables H. Peter Anvin
2016-02-19 21:19 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160721235336.GB5537@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jbaron@akamai.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=ming.lei@canonical.com \
--cc=mingo@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).