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 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


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