headers
H.J. Lu | 1 Feb 01:07
Picon
Favicon

The Linux binutils 2.22.52.0.1 is released

Hi,

The Linux binutils source tar ball is available from:

http://www.kernel.org/pub/linux/devel/binutils/

again.  I also uploaded tar balls for some older releases, dating back
to release 2.21.51.0.5.  

H.J.
---
This is the beta release of binutils 2.22.52.0.1 for Linux, which is
based on binutils 2012 0131 in CVS on sourceware.org plus various
changes. It is purely for Linux.

All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.

Starting from the 2.21.51.0.3 release, you must remove .ctors/.dtors
section sentinels when building glibc or other C run-time libraries.
Otherwise, you will run into:

http://sourceware.org/bugzilla/show_bug.cgi?id=12343

Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.

Starting from the 2.21.51.0.2 release, binutils fully supports compressed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph S. Myers | 1 Feb 22:05

Defining predefined macros for whole translation unit, revisited

C99 has standard macros __STDC_IEC_559__, __STDC_IEC_559_COMPLEX__ and 
__STDC_ISO_10646__ that are required to be constant throughout the 
translation unit (rather than, as at present, being defined in 
<features.h> so undefined before system headers are included).  C11, and 
various TRs and standards adding optional C (language and library) 
features, add further such macros that describe properties of the compiler 
and library together - or sometimes just library properties.

I previously proposed an approach of providing a <stdc-predef.h>, split 
out of <features.h>, with just these definitions, to be preincluded 
automatically by GCC if it exists (and included explicitly by <features.h> 
for use with older compilers).  The patch was posted in 
<http://sourceware.org/ml/libc-alpha/2009-04/msg00005.html> (and the GCC 
patch approved conditional on the glibc one) and 
<http://sourceware.org/bugzilla/show_bug.cgi?id=10110>; there was one 
objection on the grounds of complexity.  (I suggested this general 
approach, and other possible uses for it, on various previous occasions as 
well, e.g. <http://sourceware.org/ml/libc-alpha/2001-11/msg00011.html>.)

I still think this change is the best approach for implementing this 
standard requirement, and so would like to know what a wider range of 
people think of it.  (Presume that the patch would be updated and retested 
if the conclusion is that it is indeed the right approach.)  Note that 
from glibc's perspective it's just another internal header, of which there 
are a great many already; all the complexity is in GCC.  Reasons for this 
approach, rather than something involving GCC extracting values when 
configured, include:

* This approach also supports having independent implementations of 
various standard C library extensions - they can provide their own
(Continue reading)

Permalink | Reply | 6 comments |
headers
Roland McGrath | 1 Feb 22:16

Re: Defining predefined macros for whole translation unit, revisited

It sounds like for libc the only change is moving the __STDC_* definitions
from features.h into another file that features.h #include's.  IMHO that is
a nice cleanup in its own right, since those definitions are quite unlike
the rest of features.h and the purpose for which I first invented it.

Thanks,
Roland
Permalink | Reply | 2 comments |
headers
Joseph S. Myers | 1 Feb 22:25

Re: Defining predefined macros for whole translation unit, revisited

On Wed, 1 Feb 2012, Roland McGrath wrote:

> It sounds like for libc the only change is moving the __STDC_* definitions
> from features.h into another file that features.h #include's.  IMHO that is
> a nice cleanup in its own right, since those definitions are quite unlike
> the rest of features.h and the purpose for which I first invented it.

Yes, exactly.  For libc it's a simple change that allows getting this bit 
of the standard right (with the larger GCC change, that now would go in 
GCC 4.8), allows getting similar things right for libdfp and other 
libraries implementing various C extensions, and could be used in future 
for better communication of other libc features to the compiler.

Anyone else have views on making this change to libc?

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com
Permalink | Reply | 1 comment |
headers
Roland McGrath | 1 Feb 22:26

Re: [PATCH] vfprint: validate nargs and argument-based offsets

> The nargs value can overflow when doing allocations, and argument-based
> offsets are not bounds-checked, allowing arbitrary memory writes via
> format strings, bypassing _FORTIFY_SOURCE protections:
> http://www.phrack.org/issues.html?issue=67&id=9
> 
> This checks for nargs overflow and validates argument-based array offsets.

Seems like a good candidate for adding a test case that demonstrates the
problems.

> +    /* Check for potential integer overflow. */

Two spaces after a period (here and below).

Thanks,
Roland
Permalink | Reply | 10 comments |
headers
Kees Cook | 2 Feb 17:04
Favicon
Gravatar

Re: [PATCH] vfprint: validate nargs and argument-based offsets

On Wed, Feb 01, 2012 at 01:26:40PM -0800, Roland McGrath wrote:
> > The nargs value can overflow when doing allocations, and argument-based
> > offsets are not bounds-checked, allowing arbitrary memory writes via
> > format strings, bypassing _FORTIFY_SOURCE protections:
> > http://www.phrack.org/issues.html?issue=67&id=9
> > 
> > This checks for nargs overflow and validates argument-based array offsets.
> 
> Seems like a good candidate for adding a test case that demonstrates the
> problems.

Excellent point. I've updated the patch now...

> > +    /* Check for potential integer overflow. */
> 
> Two spaces after a period (here and below).

Fixed.

-Kees

2012-02-02  Kees Cook  <keescook <at> chromium.org>

	* stdio-common/vfprintf.c (vfprintf): Checks for nargs overflow and
	validates argument-based array offsets.
	* stdio-common/tst-vfprintf-nargs.c: New file.
	* stdio-common/Makefile (tests): Add nargs overflow test.

diff --git a/stdio-common/Makefile b/stdio-common/Makefile
index 006f546..7d34b7a 100644
(Continue reading)

Permalink | Reply | 9 comments |
headers
Ryan S. Arnold | 2 Feb 19:03
Picon

Re: [PATCH] vfprint: validate nargs and argument-based offsets

On Thu, Feb 2, 2012 at 10:04 AM, Kees Cook <kees <at> outflux.net> wrote:
> 2012-02-02  Kees Cook  <keescook <at> chromium.org>
>
>        * stdio-common/vfprintf.c (vfprintf): Checks for nargs overflow and
>        validates argument-based array offsets.
>        * stdio-common/tst-vfprintf-nargs.c: New file.
>        * stdio-common/Makefile (tests): Add nargs overflow test.

Hi Kees, Thanks for the contribution.

The addition of the tst-vfprintf-nargs file makes this contribution
legally significant.  Please verify your FSF copyright-assignment
status with your employer.

> diff --git a/stdio-common/Makefile b/stdio-common/Makefile
> index 006f546..7d34b7a 100644
> --- a/stdio-common/Makefile
> +++ b/stdio-common/Makefile
> @@ -60,7 +60,8 @@ tests := tstscanf test_rdwr test-popen tstgetln test-fseek \
>         tst-popen tst-unlockedio tst-fmemopen2 tst-put-error tst-fgets \
>         tst-fwrite bug16 bug17 tst-swscanf tst-sprintf2 bug18 bug18a \
>         bug19 bug19a tst-popen2 scanf13 scanf14 scanf15 bug20 bug21 bug22 \
> -        scanf16 scanf17 tst-setvbuf1 tst-grouping bug23 bug24
> +        scanf16 scanf17 tst-setvbuf1 tst-grouping bug23 bug24 \
> +        tst-vfprintf-nargs
>
>  test-srcs = tst-unbputc tst-printf
>
> diff --git a/stdio-common/tst-vfprintf-nargs.c b/stdio-common/tst-vfprintf-nargs.c
> new file mode 100644
(Continue reading)

Permalink | Reply | 6 comments |
headers
Roland McGrath | 2 Feb 19:49

Re: [PATCH] vfprint: validate nargs and argument-based offsets

> I believe that you should add a GLIBC copyright header, including
> copyright year and a "Contributed by " statement but perhaps someone
> else with an opinion can comment.

Certainly it should have a standard copyright comment.
Please make the first line a file-describing comment rather
than just the copyright line.

Adding "Contributed by" or "Written by" is entirely up to the author.
Some people like to be credited explicitly in more places, while for
others the ChangeLog and source control history are more than enough.
I don't add them, since it's just another way for randoms to find your
name and email address on some code and ask you truly bizarre and
unrelated questions a decade later (trust me, you have no idea).
(This isn't really relevant for a simple test case that won't change
much, but in the general case such lines can be awkward because nobody
wants to slight the original author by removing them, but over time
the file is likely to be added to or rewritten substantially by
someone else, making the credit imprecise at best.)

Thanks,
Roland
Permalink | Reply | 4 comments |
headers
Roland McGrath | 2 Feb 20:01

Re: [PATCH] vfprint: validate nargs and argument-based offsets

> +	 tst-vfprintf-nargs

We tend to call them bug-foo when they are regression tests for particular
bugs found in the past, and tst-foo when they are preemptively-written
tests.  But there is no real consistency about that and nobody really cares.

This really warrants a bugzilla report.  Then you should put:
	[BZ #nnn]
at the top of the ChangeLog stanza.  It's probably also worthwhile to
mention the bug reference inside the test case source.

> +int

Make a function static whenever it can be.

> +format_failed(const char *fmt, const char *expected, int wanted)

Space before paren (here and many other places).

> +  /* Since the stack could be extremely wrecked by this test, use
> +     an external supervisor process to catch the signals, since a
> +     signal handler may not be able to recover.
> +   */

*/ goes on the preceding line, after two spaces.

I'll give some more style comments below for future reference.
But this part doesn't actually belong here.  Use the test-skeleton.c
framework instead.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ryan S. Arnold | 2 Feb 20:11
Picon

Re: [PATCH] vfprint: validate nargs and argument-based offsets

On Thu, Feb 2, 2012 at 1:01 PM, Roland McGrath <roland <at> hack.frob.com> wrote:
>> +  if (sizeof(long) == 4)
>
> We eschew implicit "int", i.e. use "long int" instead of "long".
>
> Contrary to what Ryan said, I think it's generally preferable to use if
> rather than #if whenever you can.  That avoids compile-time bit rot in the
> code path that someone doesn't remember to update and doesn't always test.

Good to know your thoughts on this going forward.  I actually grepped
through the source and didn't find any tests with precedence for a
runtime check but I'll do/recommend this in the future.

Ryan S. Arnold
Permalink | Reply | 0 comments |

Gmane