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]

Message-ID: <20121207190244.GB29618@mudshark.cambridge.arm.com>
Date:	Fri, 7 Dec 2012 19:02:44 +0000
From:	Will Deacon <will.deacon@....com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	"Jon Medhurst (Tixy)" <tixy@...aro.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rabin Vincent <rabin@....in>, Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: ftrace: Ensure code modifications are synchronised
 across all cpus

Hi Steve,

On Fri, Dec 07, 2012 at 06:43:25PM +0000, Steven Rostedt wrote:
> On Fri, 2012-12-07 at 18:13 +0000, Russell King - ARM Linux wrote:
> > Even changing it to a breakpoint is potentially problematical.  So we'd
> > need to ensure that no other CPU was executing the code while we modify
> > it.
> 
> This is not the same as x86, I guess because x86 has a one byte
> breakpoint. Thus, it is stated in the x86 architecture (I believe,
> Peter, you can correct me if I'm wrong), that the only "safe" thing that
> can modify code, is a software breakpoint.
> 
> Are you saying that thumb does not guarantee even software breakpoints
> from being added atomically? Doesn't that kill the purpose of a
> breakpoint?

For ARMv7, there are small subsets of instructions for ARM and Thumb which
are guaranteed to be atomic wrt concurrent modification and execution of
the instruction stream between different processors:

Thumb:	The 16-bit encodings of the B, NOP, BKPT, and SVC instructions.
ARM:	The B, BL, NOP, BKPT, SVC, HVC, and SMC instructions.

but before your eyes light up at the presence of the BKPT instruction in
that list; we don't actually use that in Linux and instead leave it for
external (i.e. JTAG) debuggers so that they can operate without getting
tangled up with spurious traps from the OS. Linux actually picks its own
undefined instructions, which are obviously not included in the lists above.

Also note that the 16-bit limitation for Thumb instructions above can
actually be used to modify *half* of a BL instruction but, to keep things
exciting, the PC-relative immediate is split across the two halves. However,
you could in theory mess around with bottom 10 bits or so, depending on the
exact encoding...

Obviously this doesn't preclude the need for cache maintenance on both D and
I side, but the atomicity guarantees are as I've described above.

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