linux-kernel - Re: [RFC] gcc feature request: Moving blocks into sections

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: <1375798783.25420.30.camel@gandalf.local.home>
Date:	Tue, 06 Aug 2013 10:19:43 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, gcc <gcc@....gnu.org>,
	Ingo Molnar <mingo@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Daney <ddaney.cavm@...il.com>,
	Behan Webster <behanw@...verseincode.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, 2013-08-05 at 11:49 -0700, Linus Torvalds wrote:

> Ugh. Why the crazy update_jump_label script stuff?

After playing with the patches again, I now understand why I did that.
It wasn't just for optimization.

Currently the way jump labels work is that we use asm goto() and place a
5 byte nop in the assembly, with some labels. The location of the nop is
stored in the __jump_table section.

In order to use either 2 or 5 byte jumps, I had to put in the actual
jump and let the assembler place the correct op code in. This changes
the default switch for jump labels. Instead of being default off, it is
now default on. To handle this, I had to convert all the jumps back to
nops before the kernel runs. This was done at compile time with the
update_jump_label script/program.

Now, we can just do the update in early boot, but is this the best way?
This means that the update must happen before any jump label is used.
This may not be an issue, but as jump labels can be used for anything
(not just tracing), it may be hard to know when the first instance is
actually used.

Also, if there is any issue with the op codes as Mathieu has been
pointing out, it would only be caught at run time (boot time).

The update_jump_label program isn't really that complex. Yes it parses
the elf tables, but that's rather standard and that method is used by
ftrace with the mcount locations (instead of that nasty daemon). It
finds the __jump_table section and runs down the list of locations just
like the boot up code does, and modifies the jumps to nops. If the
compiler does something strange, it would be caught at compile time not
boot time.

Anyway, if you feel that update_jump_label is too complex, I can go the
"update at early boot" route and see how that goes.

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