linux-kernel - Re: [PATCH] ARM: ftrace: Ensure code modifications are synchronised across all cpus

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]

Date:	Fri, 7 Dec 2012 16:23:46 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	"Jon Medhurst (Tixy)" <tixy@...aro.org>,
	linux-arm-kernel@...ts.infradead.org,
	Ingo Molnar <mingo@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Rabin Vincent <rabin@....in>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: ftrace: Ensure code modifications are
	synchronised across all cpus

On Fri, Dec 07, 2012 at 10:28:54AM -0500, Steven Rostedt wrote:
> On Fri, 2012-12-07 at 14:55 +0000, Jon Medhurst (Tixy) wrote:
> >  
> > > But also realize that function tracing is special :-) We have no cases
> > > like this. The instruction being replaced is a call to mcount. In fact,
> > > we replace it at boot with a nop. And this method only replaces that nop
> > > into a call to function tracer, or replaces the call to function tracer
> > > back to a nop. Always at the start of the function, and never involved
> > > with conditionals. This limitation that function tracing imposes on what
> > > we replace makes things a bit more sane in how we replace it.
> > 
> > Then perhaps the method you suggest will work on ARM :-). However, that
> > is not something I personally propose to implement at this time. (I was
> > doing my good Samaritan act by trying to fix the crashes which another
> > team was getting when trying to use ftrace.)
> > 
> 
> I'm not NACKing your previous patch, I was just suggesting to bring ARM
> up to the future :-)
> 
> I have no problems with the patch, but I just want to put it out there
> that there's better ways. It's part of the remove stomp_machine()
> crusade ;-)

That's fine if there are better ways.  If your view is that this would
bring things "up to the future" consider this: what you suggest is possible
with the standard ARM 32-bit instruction set.  With the more modern Thumb
instruction set, because we now effectively have prefixes, where those
prefixes control the execution of the following instructions, what you
suggest becomes no longer possible.

So, it's not a question of bringing stuff up to the future at all... you
can call it a design regression of you will, but you're really making
demands about how CPUs work which are outside of your remit.

Think of this a bit like you changing the opcodes immediately following a
'LOCK' prefix on x86.  I suspect divorsing the following opcodes from its
prefix would be very bad for the instructions atomicity.
--
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/