| Message ID | 1511821819-5496-1-git-send-email-me@tobin.cc |
|---|---|
| Headers | show |
| Series | kallsyms: don't leak address when printing symbol | expand |
On Mon, Nov 27, 2017 at 2:30 PM, Tobin C. Harding <me@tobin.cc> wrote: > This is an RFC for two reasons. > > 1) I don't know who this patch set may break? > 2) Patch set includes a function that is not called. Function is there > to facilitate fixing breakages. > > _If_ no one gets broken then we can remove the unused function. > > Thanks for looking at this. > > Currently if a pointer is printed using %p[ssB] and the symbol is not > found (kallsyms_lookup() fails) then we print the actual address. This > potentially leaks kernel addresses. We could instead print something > _safe_. If kallsyms is made to return an error then callers of > sprint_symbol() can decide what to do. > > In the case of vsprintf we can print '<no-symbol>' (patch 2). > > In the case of trace we want the address so we can check the return code > and print the address if no symbol is found (patch 3). > > Design for this set loosely suggested by Steve Rostedt (so as not to > break ftrace). If tracing is the only place this is needed, this series seems reasonable to me. -Kees > > > Patch 1 and 2 tested, patch 3 (trace stuff) untested :) > > thanks, > Tobin. > > Tobin C. Harding (3): > kallsyms: don't leak address when symbol not found > vsprintf: print <no-symbol> if symbol not found > trace: print address if symbol not found > > include/linux/kernel.h | 2 ++ > kernel/kallsyms.c | 6 ++++-- > kernel/trace/trace.h | 24 ++++++++++++++++++++++++ > kernel/trace/trace_events_hist.c | 6 +++--- > lib/vsprintf.c | 18 +++++++++++++++--- > 5 files changed, 48 insertions(+), 8 deletions(-) > > -- > 2.7.4 >
On Mon, Nov 27, 2017 at 04:52:21PM -0800, Kees Cook wrote: > On Mon, Nov 27, 2017 at 2:30 PM, Tobin C. Harding <me@tobin.cc> wrote: > > This is an RFC for two reasons. > > > > 1) I don't know who this patch set may break? > > 2) Patch set includes a function that is not called. Function is there > > to facilitate fixing breakages. > > > > _If_ no one gets broken then we can remove the unused function. > > > > Thanks for looking at this. > > > > Currently if a pointer is printed using %p[ssB] and the symbol is not > > found (kallsyms_lookup() fails) then we print the actual address. This > > potentially leaks kernel addresses. We could instead print something > > _safe_. If kallsyms is made to return an error then callers of > > sprint_symbol() can decide what to do. > > > > In the case of vsprintf we can print '<no-symbol>' (patch 2). > > > > In the case of trace we want the address so we can check the return code > > and print the address if no symbol is found (patch 3). > > > > Design for this set loosely suggested by Steve Rostedt (so as not to > > break ftrace). > > If tracing is the only place this is needed, this series seems reasonable to me. Noob question: how do we _know_ this. In other words how do we know no userland tools rely on the current behaviour? No stress to answer Kees, this is a pretty general kernel dev question. thanks, Tobin.
On Tue, Nov 28, 2017 at 7:20 AM, Tobin C. Harding <me@tobin.cc> wrote: > > Noob question: how do we _know_ this. In other words how do we know no > userland tools rely on the current behaviour? No stress to answer Kees, > this is a pretty general kernel dev question. Perhaps I'm reading this wrong, but anyway: besides ftrace, kprobes will require a symbol-to-address lookup. Specifically, in the function kprobe_lookup_name() which in turn invokes kallsyms_lookup_name(). AFAIK, SystemTap (userland) is built on top of the kprobes infrastructure.. thanks, Kaiwan.
On Tue, Nov 28, 2017 at 08:58:44AM +0530, Kaiwan N Billimoria wrote: > On Tue, Nov 28, 2017 at 7:20 AM, Tobin C. Harding <me@tobin.cc> wrote: > > > > Noob question: how do we _know_ this. In other words how do we know no > > userland tools rely on the current behaviour? No stress to answer Kees, > > this is a pretty general kernel dev question. > > Perhaps I'm reading this wrong, but anyway: besides ftrace, kprobes > will require a > symbol-to-address lookup. Specifically, in the function > kprobe_lookup_name() which > in turn invokes kallsyms_lookup_name(). We should be right for this call chain because the patch doesn't touch kallsyms_lookup_name(). > AFAIK, SystemTap (userland) is built on top of the kprobes infrastructure.. This actually indirectly answers the concern. Since no userland tool should be looking up a kernel address the only code we can break is kernel code. thanks, Tobin