linux-kernel - "m" constraints, jumps, and alternatives

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-next>] [day] [month] [year] [list]

Message-ID: <53068F5C.9000008@zytor.com>
Date:	Thu, 20 Feb 2014 15:27:24 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	"H.J. Lu" <hjl.tools@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: "m" constraints, jumps,  and alternatives

Hi all,

The alternatives mechanism suffers from problems whenever there are
PC-relative items in the instruction stream.  We currently have a hack
in the alternatives mechanism where we detect the opcode of a call or
jmp instruction and adjust the offset, but that only works if the
replacement code consists solely of a call or jmp.

Well, when there are "m" contraints, we could end up with PC-relative
offsets if someone were to point the function in question at a global
variable on 64 bits.  This is much harder to decode at runtime; doing so
would require pretty much a full x86 decoder (which we do have one in
the kernel now, but it would be pretty slow I would think.)

I talked with H.J. about this, and one way to do this would be to do
post-linkage fixup of the alternatives section.  This does, however,
would seem to not work easily with kernel modules, as the kernel module
is left pre-link.  We could, of course, do equivalent fixup in the
kernel at module insertion time, since the module will include the
relocations.

Another option is to say "don't do that then", and weed out the current
uses of "m" and instead force the pointer in question explicitly into a
register.

What do you guys think?

	-hpa

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