linux-kernel - Re: [PATCH 0/5] ftrace: to kill a daemon

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <863e9df20808090801p7f9e11bar84d0e661440d591e@mail.gmail.com>
Date:	Sat, 9 Aug 2008 20:31:45 +0530
From:	"Abhishek Sagar" <sagar.abhishek@...il.com>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Peter Zijlstra" <peterz@...radead.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"David Miller" <davem@...emloft.net>,
	"Mathieu Desnoyers" <mathieu.desnoyers@...ymtl.ca>,
	"Roland McGrath" <roland@...hat.com>,
	"Ulrich Drepper" <drepper@...hat.com>,
	"Rusty Russell" <rusty@...tcorp.com.au>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Gregory Haskins" <ghaskins@...ell.com>,
	"Arnaldo Carvalho de Melo" <acme@...hat.com>,
	"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
	"Clark Williams" <williams@...hat.com>
Subject: Re: [PATCH 0/5] ftrace: to kill a daemon

On Sat, Aug 9, 2008 at 6:31 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> Dynamically modifying text that might be in the pipeline on another CPU
> may or may not be dangerous on all archs.

Kprobes leaves this mess for individual archs to handle (see
arch_arm_kprobe). What would be nice to have is an explanation as to
which archs are safe from this and under what conditions. Also, for
!SMP, this boot-time patching approach and the associated build time
paraphernalia would simply be a bloat. There we can simply have a
daemonless ftrace which patches mcount sites synchronously. Why not
let each arch have this hinge on CONFIG_SMP?

> The fix here is to convert the mcount calls to nops at boot up. This is
> really ideal on all archs. This means we know ever mcount call, and we get
> rid of the requirement that we need to run the code once before we can
> trace it.

This solution indeed would fit all archs well but for some it may be
an overkill (or is it?...I'd like to know that :-\ ).

Oh and as you pointed out, it would mean that we have to no longer run
the code before starting to trace it. But why don't we do that now?
How about calling the tracer from ftrace_record_ip? All we need to do
is pass along the parent_ip from mcount.

> The kstop_machine is now only left at the start and stop of tracing.

This a nice fix. I'm just looking to find out what the self modifying
code problem here translates to on different archs for my own
understanding :-)

Thanks,
Abhishek Sagar
--
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/