This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Support for Intel X1000


On Wed, May 13, 2015 at 08:28:32PM +0200, Florian Weimer wrote:
> On 05/13/2015 07:08 PM, dalias@libc.org wrote:
> 
> > Also, since it's not just glibc you would have to hack the lock prefix
> > out of, but also all code generated by GCC or other compilers and any
> > hand-written asm, it would make a lot more sense to put the hack that
> > NOPs out the lock prefix into the assembler. Then you can just build
> > all programs with the hacked binutils and get working binaries.
> 
> -momit-lock-prefix already exists in gas:
> 
> <https://sourceware.org/binutils/docs/as/i386_002dOptions.html>
> 
> Unfortunately, just does that:
> 
>       /* Some processors fail on LOCK prefix. This options makes
>          assembler ignore LOCK prefix and serves as a workaround.  */
>       if (omit_lock_prefix)
>         {
>           if (i.tm.base_opcode == LOCK_PREFIX_OPCODE)
>             return;
>           i.prefix[LOCK_PREFIX] = 0;
>         }
> 
> Which means that instruction offsets change, hardly a conservative approach.

And it does nothing to keep the dangerous code from running on normal
x86 Linux.

I did a little bit of research and it appears that only lock-prefixed
instructions which can page fault are affected by this bug. So why not
just make the kernel enforce mlockall for all processes on affected
cpus? I'm not clear on whether the bug crashes the whole system or
just clobbers the user process state in an unrecoverable way, but if
it's the latter, only writable pages would need to be locked;
read-only pages could still be paged normally.

It's really a shame how little publicity this bug has gotten, being
that it's probably the worst (in terms of inability to work around,
and dangerous impact of the attempted workarounds) Intel errata yet,
and that the previous reports/patches sent to binutils did not receive
any scrutiny despite being obviously-a-bad-idea...

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]