linux-kernel - Re: [RFC] [PATCH 0/2] x86: make jump labels use int3-based breakpoint instead of stop

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: <1373560944.17876.41.camel@gandalf.local.home>
Date:	Thu, 11 Jul 2013 12:42:24 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Jason Baron <jbaron@...mai.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	mathieu.desnoyers@...icios.com
Subject: Re: [RFC] [PATCH 0/2] x86: make jump labels use int3-based
 breakpoint instead of stop_machine()

On Thu, 2013-07-11 at 02:04 +0200, Jiri Kosina wrote:

> I even have preliminary (completely untested) patch, but would like to 
> have this merged/acked in the first round before proceeding with porting 
> ftrace to the new interface.
> 
> > Also, I wonder if its worth batching up updates. For example, right now 
> > we simply update each call-site one at a time even if its associated 
> > with the same control variable.
> 
> That does seem to make sense indeed, but it's not really closely tied to 
> this patchset, is it?

If you want to have ftrace use this interface, then we need to support
batch processing. And you will need to do it with an iterator as well.
We can not allocate 30,000 locations to run this on. Ftrace has its own
table, and uses the ftrace iterator to traverse it.

Thus you would need to do something like:

int text_poke_iterator(struct text_poke_iter *iterator)
{
	struct text_poke_iter_instance *iter;

	for (iter = text_poke_iterator_start(iterator);
	     iter;
	     iter = text_poke_iterator_next(iterator)) {
		ret = add_breakpoints(iter->addr, iter->old);
		if (!ret)
			goto failed;
	}

	on_each_cpu(do_sync_core, NULL, 1);
	/* and this doesn't even handle the issue with ftrace
	  start up code */

	for (iter = text_poke_iterator_start(iterator);
	     iter;
	     iter = text_poke_iterator_next(iterator)) {
		ret = add_update(iter->addr, iter->old, iter->new);
		if (!ret)
			goto failed;
	}

	on_each_cpu(do_sync_core, NULL, 1);

	for (iter = text_poke_iterator_start(iterator);
	     iter;
	     iter = text_poke_iterator_next(iterator)) {
		ret = remove_breakpoints(iter->addr, iter->new);
		if (!ret)
			goto failed;
	}

	on_each_cpu(do_sync_core, NULL, 1);

	return 0;
failed:
	for (iter = text_poke_iterator_start(iterator);
	     iter;
	     iter = text_poke_iterator_next(iterator)) {
		ret = remove_breakpoints_fail(iter->addr, iter->old, iter->new);
	}
}

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