[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <55105251.6070807@plumgrid.com>
Date: Mon, 23 Mar 2015 10:50:09 -0700
From: Alexei Starovoitov <ast@...mgrid.com>
To: Ingo Molnar <mingo@...nel.org>,
David Laight <David.Laight@...LAB.COM>
CC: Steven Rostedt <rostedt@...dmis.org>,
Namhyung Kim <namhyung@...nel.org>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Jiri Olsa <jolsa@...hat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
"David S. Miller" <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v10 tip 5/9] tracing: allow BPF programs to call bpf_trace_printk()
On 3/23/15 5:07 AM, Ingo Molnar wrote:
>
> * David Laight <David.Laight@...LAB.COM> wrote:
>
>> From: Alexei Starovoitov
>>> Debugging of BPF programs needs some form of printk from the program,
>>> so let programs call limited trace_printk() with %d %u %x %p modifiers only.
>>
>> Should anyone be allowed to use BPF programs to determine the kernel
>> addresses of any items?
>> Looks as though it is leaking kernel addresses to userspace.
>> Note that the problem is with the arguments, not the format string.
>
> All of these are privileged operations - inherent if you are trying to
> debug the kernel.
yep.
There is a plan to add 'pointer leak detector' to bpf verifier and
'constant blinding' pass, so in the future we may let unprivileged
users load programs. seccomp will be first such user. But it will
take long time.
--
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/
Powered by blists - more mailing lists