This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: "dalias at libc dot org" <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Kinsella, Ray" <ray dot kinsella at intel dot com>, "carlos at redhat dot com" <carlos at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 14 May 2015 21:24:33 -0400
- Subject: Re: Support for Intel X1000
- Authentication-results: sourceware.org; auth=none
- References: <1431426490 dot 3246 dot 29 dot camel at intel dot com> <5552104C dot 1020806 at redhat dot com> <20150512152207 dot GW17573 at brightrain dot aerifal dot cx> <1431513937 dot 2622 dot 24 dot camel at intel dot com> <20150513170809 dot GY17573 at brightrain dot aerifal dot cx> <555397D0 dot 70808 at redhat dot com>
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