This is the mail archive of the
mailing list for the glibc project.
Re: Potential issue with strstr on x86 with sse4.2 in glibc-2.18
- From: Rich Felker <dalias at aerifal dot cx>
- To: Allan McRae <allan at archlinux dot org>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, libc-alpha at sourceware dot org
- Date: Mon, 19 Aug 2013 19:06:44 -0400
- Subject: Re: Potential issue with strstr on x86 with sse4.2 in glibc-2.18
- References: <520E181D dot 2040308 at archlinux dot org> <alpine dot LNX dot 2 dot 00 dot 1308191628370 dot 2626 at monopod dot intra dot ispras dot ru> <20130819144648 dot GF20515 at brightrain dot aerifal dot cx> <alpine dot LNX dot 2 dot 00 dot 1308191924490 dot 2626 at monopod dot intra dot ispras dot ru> <5212A278 dot 3090909 at archlinux dot org>
On Tue, Aug 20, 2013 at 08:55:52AM +1000, Allan McRae wrote:
> On 20/08/13 01:54, Alexander Monakov wrote:
> > On Mon, 19 Aug 2013, Rich Felker wrote:
> >> Really this doesn't even look like a case of a legacy binary, but
> >> rather fglrx's libGL.so.1 simply containing incorrect asm (or just
> >> CFLAGS?) that doesn't match the modern psABI calling convention. It
> >> would probably be best to pressure its maintainers to fix this bug on
> >> their side...
> > I'm afraid what's more likely to happen in practice is distributions being
> > pressured by users to pick up the patch reinstating the inline keywords in
> > strstr.c. Allan, what are you going to do in Arch Linux about this? Keep
> > patching upstream, or drop the patch, let FGLRX break and tell users to
> > complain to AMD, or... ? [I do realize that the two former options are bad]
> Currently I have reinstated the inline keyword for Arch Linux. We have
> no issues declaring no support for FGRLX, because we do not support it
> anyway! AMD are too slow at updating with Xorg releases so we dropped
> it from our repos.
> But the most important thing, the person who bisected this fix was not
> using fgrlx for their libGL.so.1. They were using Mesa. And I see
> reports of Skype and Steam failing with both Intel and NVIDIA drivers.
> So binary blobs failing for all graphics drivers, and widespread
> failures for FGRLX.
> So does that just leave us the option of realigning the stack for the
> relevant calls?
Does -mincoming-stack-boundary=2 -mpreferred-stack-boundary=4 cause
realignment to take place in the prologue of every function, or only
functions that use SSE? If the latter, I think a safe solution would
be to use these options globally, and possibly the related
-mstackrealign or force_align_arg_pointer attribute on functions which
call back to application code. This would fix the problem not just for
the "relevant" calls, but for any functions in which GCC happens to
emit SSE code. Of course the size and performance costs would need to