linux-kernel - Re: [PATCH 1/5] ftrace: Synchronize variable setting with breakpoints

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]

Message-ID: <1338495969.28384.119.camel@twins>
Date:	Thu, 31 May 2012 22:26:09 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	"H. Peter Anvin" <hpa@...or.com>, Dave Jones <davej@...hat.com>,
	Andi Kleen <ak@...ux.intel.com>, acme <acme@...stprotocols.net>
Subject: Re: [PATCH 1/5] ftrace: Synchronize variable setting with
 breakpoints

On Thu, 2012-05-31 at 16:10 -0400, Steven Rostedt wrote:
> On Thu, 2012-05-31 at 15:55 -0400, Mathieu Desnoyers wrote:
> 
> > > Also, why did Mathieu insist on keeping that kmap()?
> > 
> > Not sure about the entire context here, but the goal of using kmap() is
> > to allow modification of text in configurations where the kernel text
> > is read-only: the kmap does a temporary shadow RW mapping that allows
> > modification of the text. Presumably that Ftrace's 30k changes are done
> > before the kernel text mapping is set to read-only ? If this is the
> > case, then it is similar to text_poke_early, which don't use the kmap
> > since it happens before kernel text gets write-protected. But text_poke
> > has to deal with RO pages.
> 
> No this is also when ftrace is enabled at runtime. The trick that ftrace
> does is to temporarially  convert the kernel text from ro to rw, and
> then back to ro when done. You can argue that this degrades the security
> of the system, but tracing every function in the kernel does too ;-)
> That's why it's a root only utility.

Right, but when you loose stop-machine you could simply do 30k
kmap_atomic/kunmap_atomic's consecutively since you're not holding
anybody up.

> Hmm, this brings up another question. By default, perf does not allow
> users to profile trace_events correct? IOW, perf does not let
> unprivileged users call text_poke()? I just tried it and got the:
> 
> $ ~/bin/perf record -e sched:sched_switch sleep 1
> Permission error - are you root?
> Consider tweaking /proc/sys/kernel/perf_event_paranoid:
>  -1 - Not paranoid at all
>   0 - Disallow raw tracepoint access for unpriv
>   1 - Disallow cpu events for unpriv
>   2 - Disallow kernel profiling for unpriv

It would, except tools/perf does stupid, its unconditionally adding
PERF_SAMPLE_RAW (even for non-sampling events), which is the bit that
requires privs.

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