Re: US-CERT Vulnerability Note VU#162289

* Brad Roberts: > Additionally, the linked to notes for GCC are reflective of the original > innaccuracies: > > http://www.kb.cert.org/vuls/id/CRDY-7DWKWM > > Vendor Statement > No statement is currently available from the vendor regarding this > vulnerability. Chad, it would be helpful if you

Re: IRA for GCC 4.4

I'm willing to try and do some benchmarking of Fortran codes using IRA (on i686 and x86_64), and report back here with figures and reduced testcases of eventual slow-downs. What is the current, stable way to build an IRA compiler and run it? Should I just get the last revision of the ira branch? Wh

Re: IRA for GCC 4.4

FX wrote: I'm willing to try and do some benchmarking of Fortran codes using IRA (on i686 and x86_64), and report back here with figures and reduced testcases of eventual slow-downs. What is the current, stable way to build an IRA compiler and run it? Should I just get the last revision of the ir

Re: IRA for GCC 4.4

> The best way to test IRA is to build and use the branch. It is easy to > compare the old RA (which is the default on the branch) and IRA (-fira > option switches IRA on). I'd recommend to try the following option sets: > -fira > -fira -fira-algorithm=CB OK, I've done that and I see a 40%

Re: IRA for GCC 4.4

FX wrote: The best way to test IRA is to build and use the branch. It is easy to compare the old RA (which is the default on the branch) and IRA (-fira option switches IRA on). I'd recommend to try the following option sets: -fira -fira -fira-algorithm=CB OK, I've done that and I se

Re: IRA for GCC 4.4

> Yes, that is known problem for -O0. The old allocator does not use global > allocator at -O0, IRA is used always even for -O0. The correct comparison > would be at -O2. Well, I guess it depends on what you understand by "correct". I guess to users, the correct comparison is whatever they are

Re: IRA for GCC 4.4

(The testcase is 400k lines of preprocessed Fortran code, 16M is size, available here: http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz) Thanks, I'll check it. Vlad, I think you should also try to understand what does trunk do with global (and without local allocation)

Re: US-CERT Vulnerability Note VU#162289

David Miller wrote:- > From: Joe Buck <[EMAIL PROTECTED]> > Date: Wed, 23 Apr 2008 08:24:44 -0700 > > > If CERT is to maintain its reputation, it needs to do better. The warning > > is misdirected in any case; given the very large number of compilers that > > these coding practices cause trouble

Question about compilation details

Hi. 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 i

Re: US-CERT Vulnerability Note VU#162289

Neil, I'm not sure I understand what you mean by the following: A program that does not satisfy this constraint is erroneous, and many compilers take advantage of this constraint to optimize code more effectively. Just because a program contains undefined behavior, does not mean that it erron

Re: US-CERT Vulnerability Note VU#162289

Neil Booth <[EMAIL PROTECTED]> writes: > At a minimum the wording should be something more like: > > In the C language, given an object OBJ and a pointer BUF into OBJ, > > char *buf; > int len; > > the C standard requires that the result of > > buf + len > > must point

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: > Neil, > > I'm not sure I understand what you mean by the following: > >> A program that does not satisfy this constraint is erroneous, and many >> compilers take advantage of this constraint to optimize code more >> effectively. > Just because a program contains undefi

Re: Official GCC git repository

On Wed, Apr 23, 2008 at 05:14:42PM -0400, Christopher Faylor wrote: >On Wed, Apr 23, 2008 at 08:09:57PM +0200, Samuel Tardieu wrote: >>> "Christopher" == Christopher Faylor <[EMAIL PROTECTED]> writes: >> >>Christopher> After consultation with Dan, I have set things up on >>Christopher> gcc.gnu.

Re: Official GCC git repository

On 24/04, Christopher Faylor wrote: | In case it isn't obvious, I don't know how to fix this. Well, I guess it fixed itself then since it's now working again :)

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: Just because a program contains undefined behavior, does not mean that it erroneous. It simply gives the compiler latitude with how to handle the undefined behavior, while still conforming. Actually, erroneous and undefined are approximately synonymous. There are var

Re: Official GCC git repository

It fixed itself. :) On Thu, Apr 24, 2008 at 12:09 PM, Christopher Faylor <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 23, 2008 at 05:14:42PM -0400, Christopher Faylor wrote: > >On Wed, Apr 23, 2008 at 08:09:57PM +0200, Samuel Tardieu wrote: > >>> "Christopher" == Christopher Faylor <[EMAIL PRO

Re: IRA for GCC 4.4

FX wrote: The best way to test IRA is to build and use the branch. It is easy to compare the old RA (which is the default on the branch) and IRA (-fira option switches IRA on). I'd recommend to try the following option sets: -fira -fira -fira-algorithm=CB OK, I've done that and I se

Use of option -fprofile-arcs is not compatible with -fprofile-use

The test case gcc.misc/bprob-1.c is compiled with fprofile-arcs / fprofile-use. The option fprofile-arcs does not enable value profiling. At the second stage compilation, the option fprofile-use enables value profiling. Within tree_find_values_to_profile, if one of the value optimizations alg

Re: IRA for GCC 4.4

On Thu, Apr 24, 2008 at 10:42:49AM -0400, Vladimir Makarov wrote: > FX wrote: > >> The best way to test IRA is to build and use the branch. It is easy to > >>compare the old RA (which is the default on the branch) and IRA (-fira > >>option switches IRA on). I'd recommend to try the following opti

Re: IRA for GCC 4.4

Joe Buck wrote: On Thu, Apr 24, 2008 at 10:42:49AM -0400, Vladimir Makarov wrote: FX wrote: The best way to test IRA is to build and use the branch. It is easy to compare the old RA (which is the default on the branch) and IRA (-fira option switches IRA on). I'd recommend to try the f

Re: US-CERT Vulnerability Note VU#162289

Robert C. Seacord wrote: The following article encapsulates my understanding of undefined behavior based on these discussions: MSC15-A. Do not depend on undefined behavior I think tha

Security vulernarability or security feature?

Dear "Cert", I originally raised this with you privately, but you are slow to respond, so I am raising this again, more concisely, and CC'd to a less private forum. (a) Arithmetic overflows have historically been a significant source of security vulnerabilities. (b) Recent versions of gcc (along

Re: Security vulernarability or security feature?

Ralph, Comments below. (a) Arithmetic overflows have historically been a significant source of security vulnerabilities. agreed. (b) Recent versions of gcc (along with other compilers) contain an optimisation that can *REMOVE* arithmetic overflows. I am very interested in seeing how thi

Re: IRA for GCC 4.4

On Thu, 2008-04-24 at 16:51 +0200, Paolo Bonzini wrote: > >> (The testcase is 400k lines of preprocessed Fortran code, 16M is size, > >> available here: > >> http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz) > >> > >> > > Thanks, I'll check it. > > Vlad, I think you should also

Re: Security vulernarability or security feature?

> 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 over

Re: Security vulernarability or security feature?

Robert, You have failed to answer my original question, and I think have failed to understand the point of the example. The example shows that what you are claiming is a vulnerability in 162289 is in fact a security feature. > that removes checks pointer arithmetic wrapping. Just to be 100% c

Re: IRA for GCC 4.4

On Thu, 2008-04-24 at 16:33 -0500, Peter Bergner wrote: > On Thu, 2008-04-24 at 16:51 +0200, Paolo Bonzini wrote: > > >> (The testcase is 400k lines of preprocessed Fortran code, 16M is size, > > >> available here: > > >> http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz) > > >> > >

Re: dg-skip-if on powerpc when multiple cpu cflags specified

On Wed, 2008-04-23 at 10:56 -0500, Joel Sherrill wrote: > Hi, > > I am returning to this issue and it is more > pressing testing powerpc on 4.3.0 and the trunk. > powerpc-rtems has gone from a relatively small > percentage of failures to >8300 and this warning > shows up a lot (5120334 times)! >

gcc-4.3-20080424 is now available

Snapshot gcc-4.3-20080424 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080424/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: dg-skip-if on powerpc when multiple cpu cflags specified

Janis Johnson wrote: On Wed, 2008-04-23 at 10:56 -0500, Joel Sherrill wrote: Hi, I am returning to this issue and it is more pressing testing powerpc on 4.3.0 and the trunk. powerpc-rtems has gone from a relatively small percentage of failures to >8300 and this warning shows up a lot (512033

Re: dg-skip-if on powerpc when multiple cpu cflags specified

On Thu, 2008-04-24 at 17:54 -0500, Joel Sherrill wrote: > Not knowing the internal details of the test harness, I > would make an ignorant guess that the command line > should be checked before it is executed. If it has multiple > -mcpu/-march options and they were not all the same, the > test sh

Re: Security vulernarability or security feature?

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 val

Re: dg-skip-if on powerpc when multiple cpu cflags specified

Janis Johnson wrote: On Thu, 2008-04-24 at 17:54 -0500, Joel Sherrill wrote: Not knowing the internal details of the test harness, I would make an ignorant guess that the command line should be checked before it is executed. If it has multiple -mcpu/-march options and they were not all the

Re: Security vulernarability or security feature?

> This clearly is insecure coding. Yes, it was intended to be an example of what gcc does with bad code. > When such assumptions are made ... the compiler may eliminate the bug > in some cases giving the programmer a false feeling that "Oh! My code > is bug free". The problem is that when the co

Re: Security vulernarability or security feature? VU#162289

Ralph, Thanks for your further explanation of this optimization. Here is what I understand. Please correct me if I am wrong on any of these points: 1. The description in VU#162289 misrepresents the problem has a length check. It is actually a check for wrap. 2. The optimization in this c

Re: dg-skip-if on powerpc when multiple cpu cflags specified

On Thu, 2008-04-24 at 18:14 -0500, Joel Sherrill wrote: > Janis Johnson wrote: > > On Thu, 2008-04-24 at 17:54 -0500, Joel Sherrill wrote: > > > > > >> Not knowing the internal details of the test harness, I > >> would make an ignorant guess that the command line > >> should be checked before it

Re: Security vulernarability or security feature? VU#162289

> Thanks for your further explanation of this optimization. Here is > what I understand. Please correct me if I am wrong on any of these > points: Points 1...5, no quibble. Now that you appear to admit that the issue is wrap-around and not a length-check, this raises the question of whether th

Re: IRA for GCC 4.4

Peter Bergner wrote: On Thu, 2008-04-24 at 16:33 -0500, Peter Bergner wrote: On Thu, 2008-04-24 at 16:51 +0200, Paolo Bonzini wrote: (The testcase is 400k lines of preprocessed Fortran code, 16M is size, available here: http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz)

Re: Security vulernarability or security feature? VU#162289

Ralph, Comments below. Length-checks are directly related to security, because they protect against buffer-overruns which are often directly exploited by attackers. It is much harder to see how reliance on wrap-around could contribute to the security of an application. The original impetus fo

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: > ... > > And: > >> Addition or subtraction of a pointer into, or just beyond, an array object >> and an integer type produces a result that does not point into, or just >> beyond, the same array object (6.5.6). >> >> is undefined behavior. So then unless the compiler can det

Re: US-CERT Vulnerability Note VU#162289

> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: Paul> Mark Mitchell wrote: >> ... >> >> And: >> >>> Addition or subtraction of a pointer into, or just beyond, an >>> array object and an integer type produces a result that does not >>> point into, or just beyond, the same array ob

Re: Security vulernarability or security feature? VU#162289

On Thu, Apr 24, 2008 at 08:37:43PM -0400, Robert C. Seacord wrote: > The original impetus for this came from a check in a sprint() function > from Plan 9. Because of the API, there was no way to test if the len > was out of bounds, but the developers wanted to make sure they weren't > wrapping

Re: Help me with the patterns

On Thu, Apr 24, 2008 at 12:01 PM, Mohamed Shafi <[EMAIL PROTECTED]> wrote: > Hello all, > > The target that i am porting in gcc 4.1.2, has the following instructions > > setb Rx, bitno > clrb Rx, bitno > > where bit bitno of Rx will either be set or reset. > > For statements like > > a |= (1