This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: Andrew Pinski <pinskia at gmail dot com>
- To: "dalias at libc dot org" <dalias at libc dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>, "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 18:38:06 -0700
- 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> <20150515012433 dot GC17573 at brightrain dot aerifal dot cx>
On Thu, May 14, 2015 at 6:24 PM, dalias@libc.org <dalias@libc.org> wrote:
> 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...
Most likely is because it is only for an embedded part which almost
nobody cares much about in general :).
Thanks,
Andrew Pinski
>
> Rich