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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ