This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "dalias at libc dot org" <dalias at libc dot org>, "Kinsella, Ray" <ray dot kinsella at intel dot com>
- Cc: "fweimer at redhat dot com" <fweimer at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 13 May 2015 14:15:49 -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>
On 05/13/2015 01:08 PM, dalias@libc.org wrote:
> On Wed, May 13, 2015 at 10:45:37AM +0000, Kinsella, Ray wrote:
>> On Tue, 2015-05-12 at 15:22 +0000, Rich Felker wrote:
>>> On Tue, May 12, 2015 at 04:38:04PM +0200, Florian Weimer wrote:
>>>> On 05/12/2015 12:28 PM, Kinsella, Ray wrote:
>>>>
>>> Not only that, but the code would not be working. In the kernel,
>>> defining UP and disabling lock prefix is sufficient because the kernel
>>> controls scheduling and interrupt masking and therefore doesn't need
>>> atomics except for synchronizing with other physical cores.
>>>
>> The X1000 with the bug is only available in a UP configuration (single
>> core, single socket), so there is no other physical cores to synchronize
>> with. Granted a glibc build targeting a UP environment like this, would
>> immediately break on a multi-core/socket system.
>
> I think it's rather dangerous to produce such binaries -- someone
> might compile on such a hacked distro and move the binary to a
> different system, unaware of the issues. If anyone is seriously
> considering this approach, I think there needs to be some way of
> tagging the binaries (e.g. using a different e_machine in the ELF
> header, or some other mechanism that will already forcibly break on
> existing x86 Linux systems) to make sure this can't happen.
>
> 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.
+1
The fix should be at the assembler level.
These binaries should never be allowed to run on a normal linux system.
c.