linux-kernel - Re: "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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CA+55aFw211LMAk=CSgOo26a-1QqpSEjmJZNJ4TSnbPnJUjPwOQ@mail.gmail.com>
Date:	Thu, 20 Feb 2014 16:30:44 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	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: Re: "m" constraints, jumps, and alternatives

On Thu, Feb 20, 2014 at 3:27 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> 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.

Passing addresses in registers is usually a *horrible* thing for the
kernel, because most of the time they are actually offsets within some
structure, and the address is almost invariably of the type
"offset(%register)". Which means that if you have to pass it as a pure
register, you are now (a) wasting a register and (b) adding an extra
"lea" or similar instruction just to do so.

Sadly, there is no good constraint for something like that. There's
"o" for "offsetable", but that is actually perfectly fine with a
PC-relative thing.

My preferred solution would be to (a) just say that it cannot be done
for replacement instructions (but is ok for the original
non-replacement one) and (b) perhaps have some build-time check of
just the replacement tables.

So then we'd at least get a build-time failure, and any users could be
taught that they have to use some obfuscation macro - I know we have
them, I can't recall their name, we've used them for the percpu stuff
- to force the address to be in a register rather than to be
%rip-relative.

Does that sound doable at all?

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