Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

1 msg	Re: Patch: delete treelang
2 msg	Seg fault in call_gmon_start
3 msg	C++ FE question: When is CLASSTYPE_VBASECLASSES...
1 msg	gcc-4.3-20080306 is now available
1 msg	Some regression numbers
2 msg	GCC 4.3.0 Status Report (2008-03-06, 2nd editio...
2 msg	Injecting data declarations?
1 msg	[tuples] Merged trunk->branch @132948
4 msg	GCC 4.3 - Error: Link tests are not allowed aft...
1 msg	Enum in namespace
6 msg	GCC 4.3.0 Status Report (2008-03-06)
1 msg	gcc-4.2-20080305 is now available
2 msg	GCC build problem
6 msg	Re: [PATCH] Make alias_sets_conflict_p less con...
1 msg	Soliciting help upgrading our bugzilla install
2 msg	Lots of new test failures on trunk due to unrec...

Linux doesn't follow x86/x86-64 ABI wrt directi...
\ Aurelien Jarno (5 Mar 2008)
. \ H. Peter Anvin (5 Mar 2008)
. . \ Joe Buck (5 Mar 2008)
. . . \ Aurelien Jarno (5 Mar 2008)
. . . . \ Michael Matz (5 Mar 2008)
. . . . . \ Joe Buck (5 Mar 2008)
. . . . . . \ Jan Hubicka (5 Mar 2008)
. . . . . . . \ Michael Matz (5 Mar 2008)
. . . . . . . . \ Joe Buck (5 Mar 2008)
. . . . . . . . . \ Richard Guenther (5 Mar 2008)
. . . . . . . . . . \ H. Peter Anvin (5 Mar 2008)
. . . . . . . . . . . \ Richard Guenther (5 Mar 2008)
. . . . . . . . . . . . \ David Miller (5 Mar 2008)
. . . . . . . . . . . . . \ Joe Buck (5 Mar 2008)
. . . . . . . . . . . . . \ Michael Matz (5 Mar 2008)
. . . . . . . . . . . . . . \ H. Peter Anvin (5 Mar 2008)
. . . . . . . . . . . . . . . \ Michael Matz (5 Mar 2008)
. . . . . . . . . . . . . . . . \ David Miller (5 Mar 2008)
. . . . . . . . . . . . . . . . . \ Joe Buck (5 Mar 2008)
. . . . . . . . . . . . . . . . \ Olivier Galibert (5 Mar 2008)
. . . . . . . . . . . \ Joe Buck (5 Mar 2008)
. . . . . . . . . . . . \ Richard Guenther (5 Mar 2008)
. . . . . . . . . . . \ Chris Lattner (5 Mar 2008)
. . . . . . . . . . . . \ Michael Matz (5 Mar 2008)
. . . . . . . . . . . . . \ Adrian Bunk (5 Mar 2008)
. . . . . . . . . . . . . . \ David Miller (5 Mar 2008)
. . . . . . . . . . . . . . \ Olivier Galibert (5 Mar 2008)
. . . . . . . . . . . . . \ Chris Lattner (6 Mar 2008)
. . . . . . . . . . . . . . \ Aurelien Jarno (6 Mar 2008)
. . . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . . . \ Chris Lattner (6 Mar 2008)
. . . . . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . . . . . \ Jakub Jelinek (6 Mar 2008)
. . . . . . . . . . . . . . . . . \ Olivier Galibert (6 Mar 2008)
. . . . . . . . . . . . . . . . . . \ Paolo Bonzini (6 Mar 2008)
. . . . . . . . . . . . . . . . . . \ Paolo Bonzini (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . \ Olivier Galibert (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . \ Andrew Haley (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . \ Joe Buck (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . \ Olivier Galibert (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . \ Paolo Bonzini (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . \ Jack Lloyd (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . \ Andrew Pinski (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . \ Paolo Bonzini (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . \ Paolo Bonzini (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . \ Jack Lloyd (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . . \ Artur Skawina (6 Mar 2008)
. . . . . . . . . . . . . . . . . . \ Robert Dewar (6 Mar 2008)
. . . . . . . . . . . . . . . . . . \ NightStrike (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . \ H.J. Lu (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . \ Jakub Jelinek (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . \ İsmail Dönmez (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . \ H.J. Lu (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . \ H.J. Lu (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . \ Robert Dewar (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . . . \ Robert Dewar (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . \ Florian Weimer (7 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . . . \ Andreas Jaeger (7 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . . \ H.J. Lu (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . . . . . . . . \ Robert Dewar (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . \ Robert Dewar (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . \ Paolo Bonzini (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . \ Paolo Bonzini (6 Mar 2008)
. . . . . . . . . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . . . . . . \ Artur Skawina (6 Mar 2008)
. . . . . . . . . . . . \ H. Peter Anvin (5 Mar 2008)
. . . . . . . . . . . . . \ Krzysztof Halasa (6 Mar 2008)
. . . . . . . . . . . \ Andi Kleen (6 Mar 2008)
. . . . . . . . . . . . \ Jakub Jelinek (6 Mar 2008)
. . . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . \ Aurelien Jarno (5 Mar 2008)
. . . . . . . . . \ Andrew Pinski (5 Mar 2008)
. . . . . . . . . \ Michael Matz (5 Mar 2008)
. . . . . . . . . . \ Joe Buck (5 Mar 2008)
. . . . . . . . . . \ David Miller (5 Mar 2008)
. . . . . . . . . . \ Olivier Galibert (5 Mar 2008)
. . . . . . . . . . . \ David Daney (5 Mar 2008)
. . . . . . . . . . . . \ Olivier Galibert (6 Mar 2008)
. . . . . . . . . . . . . \ Alexandre Oliva (8 Mar 2008)
. . . . . . . \ H. Peter Anvin (5 Mar 2008)
. . . . . \ H. Peter Anvin (5 Mar 2008)
. . . . . . \ Aurelien Jarno (5 Mar 2008)
. . . . . . . \ David Miller (5 Mar 2008)
. . . . . . . \ Andrew Haley (6 Mar 2008)
. . . . . . . . \ Andi Kleen (6 Mar 2008)
. . . . . . . . . \ Richard Guenther (6 Mar 2008)
. . . . . . . . . . \ Joe Buck (6 Mar 2008)
. . . . . . . . . . . \ Richard Guenther (6 Mar 2008)
. . . . . . . . . . . . \ H. Peter Anvin (6 Mar 2008)
. . . . . . . . . . . . . \ Andi Kleen (6 Mar 2008)
. . . . . . . . . . . . . . \ Richard Guenther (6 Mar 2008)
. . . . . . . . . . . . . . \ Chris Lattner (7 Mar 2008)
. . . . . . . . . . . . . . \ Michael Matz (7 Mar 2008)
. . . . \ Mikael Pettersson (6 Mar 2008)
. \ H.J. Lu (5 Mar 2008)

3 msg	gcc 3.3.2 Wind River VxWorks PowerPC
4 msg	[PATCH] BIT_FIELD_REF_UNSIGNED considered harmful
4 msg	[tuples] Branch frozen (again)

Subject:	Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Group:	Gcc
From:	Alexandre Oliva
Date:	8 Mar 2008

On Mar 6, 2008, Olivier Galibert <galibert> wrote:

> It's extremely rare, no doubt about it. It's just that it *yells*
> security issue in the making. It's not a source bug, i.e. not easily
> reviewable. It's related to signal handlers which are the mark of a
> server and/or more failure-conscious program than usual. It's obscure
> (breaking a stringop, probably memset, or a not-paranoid-enough inline
> asm in a signal handler through a running memmove in the main program,
> oh my) but reasonably predictable for someone looking for an
> exploitable flaw.

> It's gcc's job to adapt to the realities of its running environment,
> not the other way around.

I smell a false dilemma here.

The problem doesn't have to be fixed/worked-around in either the
kernel or GCC. Per your argument, one might claim it's the userland
library's, or even the application's job to adapt to the realities of
its running environment.

GCC doesn't know what functions are signal handlers to insert cld in
them. How could it fix the problem, then? How could it possibly fix
custom assembly? How could it possibly fix object code containing
signal handlers, compiled by other compilers?

A userland system library, in theory, knows what functions are signal
handlers. It could wrap function pointers passed as arguments to
signal() such that they get cld. But then, applications that couldn't
care less about this would take a hit.

Applications, on the other hand, know when they might need cld. So,
per your argument, they should adapt to the realities of their running
environment, and add asm("cld"); to signal handlers that might need
it. At times, it may be hard for them to know whether they need it,
because too many factors may affect this need. E.g.:

- if the kernel does cld for them, then they don't need it. But
that's a run-time property, so it can't be tested at build time: the
code may run on a different kernel that doesn't do it.

- if none of the libraries they use mess with this flag, or none of
the libraries they use from signal handlers depend on this flag, then
they don't need it. But then, again, libraries may vary over time,
and you can't assume the (dynamic) library that's available at build
time will behave the same way at run time.

So an application would have to do it conservatively, adding cld to
their signal handlers just in case.

But then, it would be more convenient if the library did it.

And then, by the same argument, it would be more convenient if the
kernel did it.

(Compiler can't do it, since it doesn't know what's a signal handler
in the general case.)

And that's an argument to support the ABI specs as they are.

It would be just silly to try to work around this deviation from the
specs, at a performance penalty, in every affected compiler, library
*and* application. And anything less than fixing all of them would be
an incomplete work around.

Which is not an argument against providing work arounds where
possible, just an argument in favor of fixing the problem where it can
be fixed for good.

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva, gcc.gnu.org}
Free Software Evangelist oliva, gnu.org}