Re: bndmov MPX instructions in dynamic linker breaks valgrind

[Roland McGrath <roland at hack dot frob dot com>]

Are you proposing a change, other than an item in the release notes?
Certainly there should have been a NEWS item added when that support went
in.  Igor, can you work one up?

Fundamentally, either you're going to get a libc that uses MPX instructions
and thus is incompatible with instruction-set emulators that can't handle
those instructions, or else you're going to get a libc whose dynamic linker
doesn't save and restore the MPX register state and thus is incompatible
with applications or shared libraries using the MPX support.

Intel addressed this in hardware by choosing instruction encodings that are
interpreted as NOPs by existing hardware.  It's too bad that existing
emulators like Valgrind are not compatible with existing hardware's
interpretation of those opcode values.

Because of Intel's assurance that the new opcode values are harmless NOPs,
we didn't put any provision in the source for building a libc without the
MPX support.  (There is a configure check for the assembler supporting the
new mnemonics, but if it doesn't then we just hand-code the instruction
bytes and produce the same code.)  If there is a sufficient rationale, it
would be easy enough to add a configure switch to disable this code.  But
given that disabling it has the effect of introducing subtle and hard to
find bugs into the MPX behavior of applications/libraries, it might well do
more harm than good to the users of a library configured that way.

We certainly will endeavor to make sure that the 2.20 release notes alert
people to this issue.  But I think that's all we really should do about it.
It's up to system-builders to choose component versions that work together.
If a new system incorporates glibc-2.20 before there is a Valgrind release
that can handle it, then that system's maintainers should backport the fix
into their packaged version of Valgrind.


Thanks,
Roland