Re: bndmov MPX instructions in dynamic linker breaks valgrind

[Markus Trippelsdorf <markus at trippelsdorf dot de>]

On 2014.08.06 at 14:18 -0700, Roland McGrath wrote:
> 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?

A NEWS item would be enough for me. (It's just not immediately obvious
what is going on, when one first encounters the issue.)

Thanks.

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

Since Intel's 14 nm process isn't working as expected, there's no
shipping MPX capable processor in sight yet. So it wouldn't hurt anyone
if MPX support would be disabled for another release or two.

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

-- 
Markus