Is it possible to include the bounds checking patch from
http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ in the gcc ebuild, perhaps
controlled by an USE variable?
I urgently need a gcc with this patch (which checks for memory accesses outside
array bounds or malloc items, really great!), because I use gcc in programming
courses for 15/16 year olds, and this patch keeps them from blowing holes in
their feet every second line of code.
However, as the patch contains additions to the C startup code and gcc's runtime
lib, having both the standard and the patched gcc around on the same system is a
mess. Hence, I'd like to have it as my one and only gcc.
The patch should not affect gcc's behaviour or the generated code in any way as
long as -fbounds-checking is not specified, any changes are activated only if
this flag is given when compiling a piece of code. It does not require any
changes to glibc, the binutils, or anything else.
Another source for the same patch for the latest gcc versions is
(see also http://gcc.gnu.org/extensions.html)
method -- this bug more relevent to your secure gentoo initiative
we will be including Propolice Stack Smashing Protection in the stable gcc as soon as we can, it's in the unstable profile now (gcc-3.2.2-r3) and in package.mask. SSP provides additional protection over bounds checking and is enabled by compiling with -fstack-protector.
Two very different patches, for two very different purposes:
* Propolice is a security extension. It protects the return address on the stack from being overwritten, with minimal time and space overhead.
* The bounds checking patch is a program testing / debugging tool, also very useful for educational purposes, introducing significant overhead and code changes. Differences between Propolice and bounds checking:
+ Bounds checking protects any local, global or dynamic heap item, not just the stack.
+ Bounds checking detects any access violating the defined size of the object being accessed, no matter if overrun or underrun, no matter if by index or by pointer. It also detects cases where pointer arithmetic makes a pointer point to an object differing from the object the pointer was originally derived from, even if the new address is perfectly valid (similar to Pascal array indexing, even stricter than Java).
+ Bounds checking gives perfect error messages (source line containing the violation, name, address and size of the object the pointer is related to, address actually accessed, kind of access).
Hence, for use in program development and in class, I need bounds checking, not
what do you think about this patch in our gcc azarah?
I don't have issues, as long as its dead code if not enabled. We need testing
though before going mainline ... see if you can merge it in -r3 if you want
what is happening to this bug? can we close it? the latest tests with bounds checkers like libmudflap in a tree-ssa gcc cvs snapshot were not successful on my side. also remember that we have propolice now protecting from linear stack overflows, together with nonexec stack like OpenWall or PaX or ExecShield this is as good as it gets i think to not trip into any speed penalties during execution flow like full bounds checking would inevitably mean.
As I said on 2003-04-08, I don't want bounds checking for security reasons, but I need it for educational purposes (and in school, the benefits of bounds checking outweigh almost any slowdown - programming exercises are not speed critical).
Hence, the checking should not be permanently enabled - I will certainly do my emerges without it! And that's exactly what the patch at http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ or ftp://nscs.fast.net/pub/binaries/boundschecking does:
If gcc is called without -fbounds-checking, it behaves like a standard gcc.
If this option is given, it generates bounds-checking code and links against special libs.
I'm still at 3.1.1, and there the patch mentioned above compiles and works perfectly.
One of my pupils built a later version of gcc (3.3.x?) with this patch a few weeks ago, also without any problems.
So the patch should be ok and should work out of the box.
hi, i am trying this with http://heanet.dl.sourceforge.net/sourceforge/boundschecking/bounds-checking-gcc-3.3.2-1.00.patch.bz2 and gcc-3.3.2-r2 now and will forward any side effects to Martin,
hi, i need to find some time to do this, i think i can do it in 3.3.3-r1 to be activated for a special USE flag given because it should not penalize the majority of users not needing it
why a USE flag ?
like the reporter said, nothing should change unless you compile with -fbounds-checking
yes, you are right, a nondefault version would work
could we take on the USE="debug" flag to activate the passive patch?
i would not like to introduce this patch by default.
only when USE="debug" is given to the gcc ebuild, this patch would be included
see it as a proper line of defense against pappy doing something wrong
is this okay for you please?
thanks in advance, Alex
Re: comment #14 use debug && epatch fbounds-xxxx.patch works for me.
Please do not overload a single USE flag. "debug" has other meanings (one effect is that it makes emerged binaries significantly larger), and it should be possible to switch these features on and off individually:
* "debug" means that I want to debug gcc (or whatever package is emerged with "debug") itself (which is not what I intend).
* The bounds checking patch is for debugging my own programs compiled with gcc - that's a completely different goal.
the bounds checking made it into pie-ssp-bounds-checking in gcc-3.3.3-r1
I've a problem with testing: All my gentoo systems are still at gcc-3.1 level, which is binary and library incompatible with gcc-3.2 or later, so I can't install and run gcc-3.3.x here.
Most likely, I will upgrade in summer and test then.
i have two open points here:
1) this patch apparently nukes the PPC when the compiler contains altivec patches, i saw a bug at Gentoo where this compiler was unable to compile and the c-bounds.c file was showing errors when running 3.3.3-r1 on PPC.
So, i am strongly recommending that we couple this patch to x86 first and see.
2) I had to couple the pie-ssp patch with the bounds checker patch.
In the long run, this is supposed to be a bad decision.
This is how it should work in the future, and will be changed by me:
- gcc source unpacked, branch update applied, arch and gentoo fixes applied
- pie-ssp patch applied (either hardened default or nondefault behaviour, does not matter in this case)
- if x86 custom bounds checker patch applied to the gentoo pie-ssp gcc source
I like to refer to the term "custom" because such a patch would be transformed from the generic original bounds-checker patch from the site you mentioned to a conforming patch that is able to be applied to our gcc source which has some "overlapping" hunks in the includes and the SPECS section mangling.
Thanks so far,
are there new patches available, Klaus?
The latest patches I could find are for 3.3.3, nothing for 3.4.x yet.
I'll ask the author by email...
Patches for 3.3.4, 3.4.0 and 3.4.1 are on http://web.inter.nl.net/hcc/Haj.Ten.Brugge/
I too would very much like to have the C bounds checking patch somehow with the gentoo ebuild gcc (curently Im compiling private versions of gcc for that). Either a USE or other solution is your choice. It's not clear to me from this thread, has the bounds checking patch been included already ? I have tried to test it and doesnt seem to be there. In that case, any work in progress ?
Does the libmudflap in gcc-3.4 suffice for this to close it finally?
Hmmm, libmudflap might provide the same functionality as the bounds-checking patch in future, but:
* It looks very beta. I have not yet found anything about its quality, there are no experiences with real-world, large programs, and I've seen no overhead comparisions with bounds-checking. (I'm still on gcc-3.3.x, so I can't test myself).
* It is completely undocumented. I searched the gcc 3.4.2 manual on the web, and it doesn't even mention "-fmudflap". I can't even tell if libmudflap detects the same kinds of pointer problems as bounds-checking does, or more, or less.
* I found a report about libmudflap. Compared to the messages of bounds-checking (which are self-explanatory), the messages libmudflap produces for pointer violations contain more info for the experienced programmer, but are cryptic for the beginner.
My intended audience are high-school programming courses, the goal is to give beginners Pascal-like help against pointer bugs. libmudflap's cryptic messages are not helpful for 15 year olds...
take it on
added to gcc-3.4.2-r2, activate with USE=boundschecking
please try and close bug.
works like a charm for me :-)
only thing that came into my mind is the fact that gcc man pages might need to be updated to honour the fact that -fbounds-checking now also is supported for C
Works nice. Thank you guys, yet again Gentoo rules :)
I will test it as soon as possible.
About man pages:
Have you checked them? Two years ago, when I manually applied the bounds-checking patch to a copy of gcc 3.1, it also patched the man pages automatically: They actually included -fbounds-checking after applying the patch!
the man reads:
For front-ends that support it, generate additional code to check that indices used to access arrays are within the declared range. This is currently only supported by the Java and Fortran 77 front-ends, where this option defaults to true and false respectively.
I think the patch used in this ebuild is a custom patch differing from the official patch - so it might lack the man page changes...
Excellent. Works for me. Thanks!
About man pages: I checked the original patch, it doesn't seem to patch the man pages any longer, but it seems to patch the info nodes for gcc.
will try to keep it updated.