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
On Thu, Feb 20, 2014 at 3:27 PM, H. Peter Anvin <[email protected]> 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