Re: Security vulernarability or security feature?
2008/4/25 Prateek Saxena <[EMAIL PROTECTED]>:
> On Thu, Apr 24, 2008 at 2:20 PM, Ralph Loader <[EMAIL PROTECTED]> wrote:
> > > I am very interested in seeing how this optimization can remove
> > > arithmetic overflows.
> >
> > int foo (char * buf, int n)
> > {
> > // buf+n may overflow of the programmer incorrectly passes
> > // a large value of n. But recent versions of gcc optimise
> > // to 'n < 100', removing the overflow.
> > return buf + n < buf + 100;
> > }
>
> This clearly is insecure coding. The optimization to replace "buf + n
> < buf + 100" with "n < 100" assumes something about the value of buf.
> I assume that the location of "buf", could change arbitrarily accross
> platforms depending on the memory layout.
> I ran foo as follows, getting different outputs :
>
>From the algebra perspective "buf + n < buf + 100" should be the same
as "n < 100". There should really be a feature in C to handle the
special overflow/carry case in order to handle overflows and wrap
arounds.
This is probably a fundamental problem with C.
If one takes the following:
int a,b,c;
a = b + c;
How does one detect if there was a signed int overflow?
Programmers are forced to jump all sorts of hoops to do this check.
Fortunately there is a assembler instruction to do just this on most CPUs.
e.g. jo, jc, js
It would be nice to be able to write this sort of C code.
int a,b,c;
a = b + c;
if (a overflowed) {
handle_overflow();
}
One cannot simply code a special function to test the carry/overflow
flags as the compiler might reorder the previous instructions, and
therefore the carry/overflow state gets messed up.
Why has the C language lacked this sort of functionality for so long?
James
Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
I want to flag the failure in bootstrapping gfortran-4.4.0-20080425 [1], observed on Cygwin. --- [...] # Now that we have built all the objects, we need to copy # them back to the GCC directory. Too many things (other # in-tree libraries, and DejaGNU) know about the layout # of the build tree, for now. make install-leaf DESTDIR=../.././gcc \ slibdir= libsubdir= MULTIOSDIR=. make[4]: Entering directory `/work/build/i686-pc-cygwin/libgcc' /bin/sh /work/gcc/libgcc/../mkinstalldirs ../.././gcc /usr/bin/install -c -m 644 libgcc.a ../.././gcc/ chmod 644 ../.././gcc/libgcc.a ranlib ../.././gcc/libgcc.a /usr/bin/install -c -m 644 libgcov.a ../.././gcc/ chmod 644 ../.././gcc/libgcov.a ranlib ../.././gcc/libgcov.a parts="crtbegin.o crtend.o crtfastmath.o";\ for file in $parts; do \ rm -f ../.././gcc/$file; \ /usr/bin/install -c -m 644 $file ../.././gcc/;\ done make[4]: Leaving directory `/work/build/i686-pc-cygwin/libgcc' make[3]: Leaving directory `/work/build/i686-pc-cygwin/libgcc' make[2]: Leaving directory `/work/build' make[2]: Entering directory `/work/build' make[3]: Entering directory `/work/build' rm -f stage_current make[3]: Leaving directory `/work/build' make[2]: Leaving directory `/work/build' make[2]: Entering directory `/work/build' Configuring stage 2 in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for i686-pc-cygwin-gcc... /work/build/./prev-gcc/xgcc -B/work/build/./prev-gcc/ -B/usr/local/gfortran/i686-pc-cygwin/bin/ checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 77 make[2]: Leaving directory `/work/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/work/build' make: *** [all] Error 2 --- Cheers, Angelo. --- gcc-core+fortran from ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080425
Re: Security vulernarability or security feature?
James Courtier-Dutton wrote:
2008/4/25 Prateek Saxena <[EMAIL PROTECTED]>:
On Thu, Apr 24, 2008 at 2:20 PM, Ralph Loader <[EMAIL PROTECTED]> wrote:
> > I am very interested in seeing how this optimization can remove
> > arithmetic overflows.
>
> int foo (char * buf, int n)
> {
> // buf+n may overflow of the programmer incorrectly passes
> // a large value of n. But recent versions of gcc optimise
> // to 'n < 100', removing the overflow.
> return buf + n < buf + 100;
> }
This clearly is insecure coding. The optimization to replace "buf + n
< buf + 100" with "n < 100" assumes something about the value of buf.
I assume that the location of "buf", could change arbitrarily accross
platforms depending on the memory layout.
I ran foo as follows, getting different outputs :
From the algebra perspective "buf + n < buf + 100" should be the same
as "n < 100". There should really be a feature in C to handle the
special overflow/carry case in order to handle overflows and wrap
arounds.
This is not algebra with natural numbers, it is C, any programmer who
analyzes expressions expecting algebraic laws of this kind to hold is
in serious trouble!
This is probably a fundamental problem with C.
If one takes the following:
int a,b,c;
a = b + c;
How does one detect if there was a signed int overflow?
Not easily indeed
Programmers are forced to jump all sorts of hoops to do this check.
Yes, this is a weakness of the language. The proper hoops in this
case are to do the addition in unsigned, and check the sign bit of
the result and operands. In cases where you know the operands are
positive, the check is of course much simpler.
Fortunately there is a assembler instruction to do just this on most CPUs.
e.g. jo, jc, js
It would be nice to be able to write this sort of C code.
int a,b,c;
a = b + c;
if (a overflowed) {
handle_overflow();
}
Yes, but there is no such feature
One cannot simply code a special function to test the carry/overflow
flags as the compiler might reorder the previous instructions, and
therefore the carry/overflow state gets messed up.
Right indeed.
You could code an addition function that did an overflow check and
call that function
Why has the C language lacked this sort of functionality for so long?
It would be a major language change, there are of course languages (e.g.
Ada) that handle this conveniently and properly. To me, the more
interesting question is how on earth Java missed this fundamental
requirement.
James
Re: Security vulernarability or security feature?
2008/4/27 Robert Dewar <[EMAIL PROTECTED]>:
>
> > Fortunately there is a assembler instruction to do just this on most CPUs.
> > e.g. jo, jc, js
> > It would be nice to be able to write this sort of C code.
> >
> > int a,b,c;
> > a = b + c;
> > if (a overflowed) {
> >handle_overflow();
> > }
> >
>
> Yes, but there is no such feature
>
>
> >
> > One cannot simply code a special function to test the carry/overflow
> > flags as the compiler might reorder the previous instructions, and
> > therefore the carry/overflow state gets messed up.
> >
>
> Right indeed.
> You could code an addition function that did an overflow check and
> call that function
>
>
> >
> > Why has the C language lacked this sort of functionality for so long?
> >
>
> It would be a major language change, there are of course languages (e.g.
> Ada) that handle this conveniently and properly. To me, the more
> interesting question is how on earth Java missed this fundamental
> requirement.
>
> >
> > James
> >
>
>
I think Java handles it OK for floats. I.e. Tests for positive
infinity and negative infinity etc.
I don't think Java handles it for integer maths. I agree with you. Big
oversight for the Java spec developers.
It would have been nice to also have some good handling of reals but
that is a compete other story.
Re: Google Summer of Code 2008: seven approved applications for gcc
On Tue, 2008-04-22 at 17:41 +0200, Manuel López-Ibáñez wrote: > And in our wiki: > > http://gcc.gnu.org/wiki/SummerOfCode > > which our new developers are welcome to use to document their progress. They are also welcome to apply for an account on the GCC Compile Farm, instructions to do so are here: http://gcc.gnu.org/wiki/CompileFarm It's always nicer to compile & test on 8 cores with 16 GB of RAM :). Laurent
Re: Security vulernarability or security feature?
James Courtier-Dutton wrote: I think Java handles it OK for floats. I.e. Tests for positive infinity and negative infinity etc. Float is another matter entirely, the problem discussed here is for integer overflow. By the way, according to microsoft developers wrt the vista code base, integer overflow problems are the second most serious source of bugs (after buffer overflows) I don't think Java handles it for integer maths. I agree with you. Big oversight for the Java spec developers. It seems strange that the huge advantage of range checked integer arithmetic, familiar for a long time from Pascal and Ada, escaped the attention of Java designers. It would have been nice to also have some good handling of reals but that is a compete other story. Not sure what you mean by reals (as opposed to float)
Re: Security vulernarability or security feature?
I think Java handles it OK for floats. I.e. Tests for positive infinity and negative infinity etc. I don't think Java handles it for integer maths. Java integer math is mandated to have wrap-around semantics. So you can do something like if ((b^c) > 0 && (a^c) < 0 && (a^b) < 0) overflow Paolo
Re: Security vulernarability or security feature?
Paolo Bonzini wrote: I think Java handles it OK for floats. I.e. Tests for positive infinity and negative infinity etc. I don't think Java handles it for integer maths. Java integer math is mandated to have wrap-around semantics. So you can do something like if ((b^c) > 0 && (a^c) < 0 && (a^b) < 0) overflow yes, and naturally in typical Java code, we see every integer addition that might overflow protected in this way :-) :-) Of course in C you can do the same, you just have to cast to unsigned if you are using signed int. Paolo
Re: Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Well, as it says so well, we need to see your config.log if we want to have any idea at all what's happening. That should be the file in intl/config.log. Thanks, FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
FX wrote: checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Well, as it says so well, we need to see your config.log if we want to have any idea at all what's happening. That should be the file in intl/config.log. There's nothing there to enlighten me. Apparently, the stage 1 gcc is broken. Cygwin native built gfortran 4.4 was already broken, even when it was making it through bootstrap and testsuite. All comments I've received told me I was wasting my time with it.
Re: Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
Cygwin native built gfortran 4.4 was already broken, even when it was making it through bootstrap and testsuite. All comments I've received told me I was wasting my time with it. Where is that bug reported? cygwin is secondary target, I think it should really be unbroken, with the help of its maintainers (and possibly by identifying the patch that broke bootstrap). FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
Is this related to http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01951.html H.J. On Sun, Apr 27, 2008 at 11:47 AM, FX <[EMAIL PROTECTED]> wrote: > > > Cygwin native built gfortran 4.4 was already broken, even when it was > making it through bootstrap and testsuite. All comments I've received told > me I was wasting my time with it. > > > > Where is that bug reported? cygwin is secondary target, I think it should > really be unbroken, with the help of its maintainers (and possibly by > identifying the patch that broke bootstrap). > > > > FX > > -- > François-Xavier Coudert > http://www.homepages.ucl.ac.uk/~uccafco/ > >
Re: IRA for GCC 4.4
On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
> > Hi, Peter. The last time I looked at the conflict builder
> > (ra-conflict.c), I did not see the compressed matrix. Is it in the
> > trunk? What should I look at?
>
> Yes, the compressed bit matrix was committed as revision 129037 on
> October 5th, so it's been there a while. Note that the old square
> bit matrix was used not only for testing for conflicts, but also for
> visiting an allocno's neighbors. The new code (and all compilers I've
> worked on/with), use a {,compressed} upper triangular bit matrix for
> testing for conflicts and an adjacency list for visiting neighbors.
>
> The code that allocates and initializes the compressed bit matrix is in
> global.c. If you remember how a upper triangular bit matrix works, it's
> just one big bit vector, where the bit number that represents the conflict
> between allocnos LOW and HIGH is given by either of these two functions:
>
> 1) bitnum = f(HIGH) + LOW
> 2) bitnum = f(LOW) + HIGH
>
> where:
>
> 1) f(HIGH) = (HIGH * (HIGH - 1)) / 2
> 2) f(LOW) = LOW * (max_allocno - LOW) + (LOW * (LOW - 1)) / 2 - LOW - 1
>
> As mentioned in some of the conflict graph bit matrix literature (actually,
> they only mention expression #1 above), the expensive functions f(HIGH) and
> f(LOW) can be precomputed and stored in an array, so to access the conflict
> graph bits only takes a load and an addition. Below is an example bit matrix
> with initialized array:
>
> 012 3456789 10 11
> ---
> | -1 | 0 || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
> ---
> | 9 | 1 ||| 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
> ---
> | 18 | 2 |||| 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 |
> ---
> | 26 | 3 ||||| 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 |
> ---
> | 33 | 4 |||||| 38 | 39 | 40 | 41 | 42 | 43 | 44 |
> ---
> | 39 | 5 ||||||| 45 | 46 | 47 | 48 | 49 | 50 |
> ---
> | 44 | 6 |||||||| 51 | 52 | 53 | 54 | 55 |
> ---
> | 48 | 7 ||||||||| 56 | 57 | 58 | 59 |
> ---
> | 51 | 8 |||||||||| 60 | 61 | 62 |
> ---
> | 53 | 9 ||||||||||| 63 | 64 |
> ---
> | 54 | 10 |||||||||||| 65 |
> ---
> | NA | 11 |||||||||||||
> ---
>
> As an example, if we look at the interference between allocnos 8 and 10, we
> compute "array[8] + 10" = "51 + 10" = "61", which if you look above, you will
> see is the correct bit number for that interference bit.
>
> The difference between a compressed upper triangular bit matrix from a
> standard
> upper triangular bit matrix like the one above, is we eliminate space from the
> bit matrix for conflicts we _know_ can never exist. The easiest case to
> catch,
> and the only one we catch at the moment, is that allocnos that are "local" to
> a
> basic block B1 cannot conflict with allocnos that are local to basic block B2,
> where B1 != B2. To take advantage of this fact, I updated the code in
> global.c
> to sort the allocnos such that all "global" allocnos (allocnos that are live
> in
> more than one basic block) are given smaller allocno numbers than the "local"
> allocnos, and all allocnos for a given basic block are grouped together in a
> contiguous range to allocno numbers. The sorting is accomplished by:
>
> /* ...so we can sort them in the order we want them to receive
> their allocnos. */
> qsort (reg_allocno, max_allocno, sizeof (int), regno_compare);
>
> Once we have them sorted, our conceptual view of the compressed bit matrix
> will now look like:
>
> GGGB0 B0 B0 B1 B1 B2 B2 B2 B2
>
>
Re: Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
FX ha scritto: Cygwin native built gfortran 4.4 was already broken, even when it was making it through bootstrap and testsuite. All comments I've received told me I was wasting my time with it. Where is that bug reported? cygwin is secondary target, I think it should really be unbroken, with the help of its maintainers (and possibly by identifying the patch that broke bootstrap). FX For the sake of completeness, the snapshots 4.4-20080418, 4.3-20080417 (a week ago) and 4.3-20080424 (recent) build fine. Cheers, Angelo.
Re: Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
H.J. Lu wrote: Is this related to http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01951.html H.J.y t Seems unlikely. I don't see that Fortran was involved in the failure, although both of us included it in configure. If it makes a difference, I'll try to bootstrap C alone tomorrow, from the subject snapshot, or something newer, if recommended and available. On Sun, Apr 27, 2008 at 11:47 AM, FX <[EMAIL PROTECTED]> wrote: Cygwin native built gfortran 4.4 was already broken, even when it was making it through bootstrap and testsuite. All comments I've received told me I was wasting my time with it. Where is that bug reported? cygwin is secondary target, I think it should really be unbroken, with the help of its maintainers (and possibly by identifying the patch that broke bootstrap). FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: dg-skip-if on powerpc when multiple cpu cflags specified
Janis Johnson wrote: This will involve editing every test that using dg-options to add a -mcpu/-march flag. Would it make sense to let dg-options check for the conflict as it adds an option? Yes, it would meaning adding the new option to hundreds of tests, but that's better than the earlier suggestion of adding a very ugly dg-skip-if to every one of those tests. I think it's even more complicated. The testsuite should not assume that options explicitly provided (a combination of the options explicitly in the test, those implicitly for the DejaGNU harness, those for the multilib being tested, and those provided in the board file) are those that govern completely. In particular, the --with-cpu configuration option, or other bits of configury, or -t options that serve as abbreviations for other options can all affect what CPU is actually being targeted. Trying to scan the list of options to see which ones are provided is too error-prone. Therefore I think there are two plausible approaches: 1. Make these tests say something about what capability they require, with a dg-require directive, and then write autoconf-style tests run by the testsuite to determine whether the current compiler has that capability. For example, add a "dg-require-hard-float" directive, and probe the compiler to see whether it can generate hard float, given all the options in play. 2. Write the tests with #ifdef's that test compiler predefines that indicate the CPU model, architecture, or available feature. For example, it would be a nice thing if something like __GNU_CPU_y__ and __GNU_TUNE_z__ were defined on all machines, corresponding to -march= and -mtune=. For example __GNU_CPU_603__ for a Power 603, or __GNU_FEATURE_ALTIVEC__ for a CPU with AltiVec support, or something. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: IRA for GCC 4.4
On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: > Don't be stupid! Could you be a bit more civil, please? It's fairly unusual for people on this list to talk to each other in this way. Thanks, Ben
Re: Question about compilation details
>I'm using the arm-elf-gcc compiler to compile some files to a ARM9 > (Freescale i.MX27, ARM926EJ-S core). What I would like to know is how > can I visualize/change the address specifications made by the linker > to the output file? I heard gcc can generate a file (.lst) that > contains such information, but I also don't know how to create this > file. This question is probably better suited to gcc-help; this list is for development discussions. However, I will try and answer your question nonetheless. ;-) I assume you're referring to a linker map. The GNU linker can create one of these -- you need to refer to the ld man page for the details (it's not really related to gcc). To pass an option to the linker, pass "-Wl," to gcc. Cheers, Ben -- Ben Elliston <[EMAIL PROTECTED]> Australia Development Lab, IBM
Implementing built-in functions for I/O
Hello all, I/O instructions are different from other instructions because there isn't any way to recognize them as i/o patterns, I guess in AVR this is possible because AVR has memory mapped i/o. So its is possible to write something like PORTA = 0xff But i couldn't find out much about other targets. For the particular target that i am porting i was able to implement 'in' instructions using builtins. So it is possible to do short k = __IN(PORTC); My question is will it be possible to implement the same for OUT instruction also. When implemented as a builtin it is not possible to do something like short k; __OUT(port no) = k; So hoe can i do that. Is inline assembly the only solution? Thanks for your time. Regards, Shafi
4.3.1 Status Report (2008-04-17)
Status == The GCC 4.3 branch is open for commits under normal release branch rules. GCC 4.3.1 is scheduled for 2008-05-05. As we have not yet built 4.3.1-rc1, we will slip that date. As shown below, there are 2 P1s on the 4.3 branch, so we are not yet ready to build RC1. One of the P1s is an ICE: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35399 is alleged to be a regression on the 4.3 branch. The other P1 involves "restrict" and apparently worked in 4.2.x, but not in 4.3.x. Quality Data Priority # Change from Last Report --- --- P1 2 - 2 P2 100 + 4 P3 1 - 8 --- --- Total103 - 6 Previous Report === http://gcc.gnu.org/ml/gcc/2008-04/msg00449.html The next report for the 4.3 branch will be sent by Joseph.
