linux-kernel - Re: [PATCH bpf-next v2] bpf: support raw tracepoints in modules

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Dec 2018 21:11:22 +0000
From:   Martin Lau <kafai@...com>
To:     Matt Mullins <mmullins@...com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "ast@...nel.org" <ast@...nel.org>,
        Kernel Team <Kernel-team@...com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next v2] bpf: support raw tracepoints in modules

On Thu, Dec 13, 2018 at 11:38:51AM -0800, Matt Mullins wrote:
> On Thu, 2018-12-13 at 19:22 +0000, Martin Lau wrote:
> > On Wed, Dec 12, 2018 at 04:42:37PM -0800, Matt Mullins wrote:
> > > Distributions build drivers as modules, including network and filesystem
> > > drivers which export numerous tracepoints.  This enables
> > > bpf(BPF_RAW_TRACEPOINT_OPEN) to attach to those tracepoints.
> > >
Acked-by: Martin KaFai Lau <kafai@...com>

[ ... ]

> > > +#ifdef CONFIG_MODULES
> > > +int bpf_event_notify(struct notifier_block *nb, unsigned long op, void *module)
> > > +{
> > > +	struct bpf_trace_module *btm, *tmp;
> > > +	struct module *mod = module;
> > > +
> > > +	if (mod->num_bpf_raw_events == 0 ||
> > > +	    (op != MODULE_STATE_COMING && op != MODULE_STATE_GOING))
> > > +		return 0;
> > > +
> > > +	mutex_lock(&bpf_module_mutex);
> > > +
> > > +	switch (op) {
> > > +	case MODULE_STATE_COMING:
> > > +		btm = kzalloc(sizeof(*btm), GFP_KERNEL);
> > > +		if (btm) {
> > > +			btm->module = module;
> > > +			list_add(&btm->list, &bpf_trace_modules);
> > > +		}
> > 
> > Is it fine to return 0 on !btm case?
> 
> That effectively just means we'll be ignoring tracepoints for a module
> that is loaded while we can't allocate a bpf_trace_module (24 bytes) to
> track it.  That feels like reasonable behavior to me.
ok.