linux-kernel - Re: [RFC PATCH 1/2] PM/runtime: introduce trace points for tracing rpm

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

Message-ID: <1317091075.26514.29.camel@gandalf.stny.rr.com>
Date:	Mon, 26 Sep 2011 22:37:53 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	rjw@...k.pl, stern@...land.harvard.edu,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	mingo@...hat.com, fweisbec@...il.com
Subject: Re: [RFC PATCH 1/2] PM/runtime: introduce trace points for tracing
 rpm_* functions

On Tue, 2011-09-27 at 09:45 +0800, Ming Lei wrote:

> > Not to mention, this will never work with tools such as perf or
> > trace-cmd, that will just get a pointer address and will try to read a
> > string that points inside the kernel.
> 
> Ok, sounds like dev_name does not work for the case, I will update
> the patch, but I am wondering why no such problem for dev_dbg?
> printk still may buffer these for sometime in some cases.
> 


printk will push out to the console immediately. Whatever is in the
buffer has already been processed into a string. With tracing, we save
the data as defined by TP_fast_assign() and is printed later when the
user asks in TP_printk().

> >
> > This will only work with reading the trace data
> > from /debug/tracing/trace, but not from any tools. The pS *will* work
> > with the tools as the tools load the kallsyms data, and is smart enough
> > to figure this pointer out.
> 
> __func__ points to a const string, which will be stored in kernel global
> read-only section, I think perf can read correct string from the pointer
> anytime, don't I?

That would be very dangerous to let a userspace app have any access to
reading the kernel memory. Not to mention, this data may be sent out
over the network to another machine, which must be able to read this
data too.

-- Steve


--
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/