[prev in list] [next in list] [prev in thread] [next in thread]
List: gcc-patches
Subject: Re: [RFC] [PATCH] Implement -ffortify for C/C++
From: Jakub Jelinek <jakub () redhat ! com>
Date: 2007-02-01 10:52:01
Message-ID: 20070201105201.GD27294 () devserv ! devel ! redhat ! com
[Download RAW message or body]
On Thu, Feb 01, 2007 at 12:34:21AM +0100, Dirk Mueller wrote:
> On Tuesday, 30. January 2007 18:05, Jakub Jelinek wrote:
>
> > > so it produces __builtin_object_size(.., 1) if it is a str*/stp* related
> > > function and fortify level is > 1. This is how I understood it from
> > > reading the glibc header file (I admit it was late and I was drunk).
> > Oops, yeah, your patch is correct, I must have missed the bos && there,
> > sorry. Still, the *.texi documentation needs fixing to actually describe
> > what the option really does.
>
> I agree. Which part do you think is missing? the definition of the parameter
> passed down to the builtin_object_size calls in str* functions depending on
> the fortify level compared to the mem* functions?
+@itemx -ffortify=@var{n}
+Instrument a set of string, memory and printf related functions into their
+_chk variants. @var{n} controls the behaviour in detail. A fortify level
+of 1 will produce compile warnings, but expand the _chk variants
+back into the non-checking equivalent, and therefore not introduce any
+run-time overhead in the generated code. A level of 2 will emit calls
The description of level 1 is wrong. The level has nothing to do with
_chk calls being produced or not.
The difference really is between allowing/rejecting standard conforming,
but dangerous or weird/most probably unintentional code.
Say:
char fmt[10];
sprintf (fmt, "%%%c%%n\\n", unsigned ? 'u' : 'd');
printf (fmt, var, &n);
is standard conforming code, accepted with -D_FORTIFY_SOURCE=1, rejected
with -D_FORTIFY_SOURCE=2. The reason for that is %n is most often
used in format string exploits, typically by preparing the format string
somewhere on the stack or on the heap and then returning to one of the
*printf family functions.
Or look e.g. at http://sourceware.org/ml/binutils/2005-03/msg00180.html
for another, real-world, code accepted with -D_FORTIFY_SOURCE=1, but
(runtime) rejected with -D_FORTIFY_SOURCE=2.
Jakub
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic