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: Andrew Pinski <pinskia at gmail dot com>
- 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 21:48:04 -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> <20150515012433 dot GC17573 at brightrain dot aerifal dot cx> <CA+=Sn1m8pTT8OZ8w_LPwtwb+=vZpp0orxUdMCcX3k75PojHQkA at mail dot gmail dot com>
On Thu, May 14, 2015 at 06:38:06PM -0700, Andrew Pinski wrote:
> 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 :).
But what's the point of embedded hardware being x86 if it's not
actually x86 but some broken almost-x86 ISA? Certainly there are much
better embedded archs you could go with if you don't care about
compatibility with x86 binaries.
Rich