Messages in this thread | | | From | (Gary Funck) | Date | Wed, 2 Aug 2000 17:27:11 -0700 | Subject | Re: Stopping buffer-overflow security exploits using page protect |
| |
On Jul 30, 9:25pm, Crispin Cowan wrote: > Gary Funck wrote: > > On Jul 29, 12:49pm, Oliver Xymoron wrote: > > > The problem isn't Intel's fault or any OS's, it's a problem in the C > > > language and compiler. There are 5 fixes: > > > > > > a) write safe code (which has so far proved hard) > > > b) compile with bounds-checking (big performance hit) > > > > What is the level of performance hit, using bounds-checking? > > > > Highly variable. The best example of a full bounds-checking C compiler > is the GCC enhancement here http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ > > Based on the compiler's documentation, it imposes between 3X and 30X > slowdowns, depending on the application. One of my favorite benchmarks > for security overhead is SSH: It's a real network service that needs to > be secure, so one really cares about the performance overhead of > protecting SSH. Based on e-mail correspondence with Kurt Roeckx (one of > the developers) this bounds checking compiler imposes a 12X slowdown > (1200% overhead) on SSH throughput.
Just fui. There's another 'bounder pointers' project, located here: http://gcc.gnu.org/proj-bp.html#status
under "Goals":
Low Overhead
Space and time overheads for bounded-pointer programs are both approx 150%..200% (i.e., 2.5x..3x slowdown and 2.5x..3x code size increase). A couple years back I implemented bounded pointers in gcc-2.7.2 with much hackage at the RTL layer, and using a special BP machine mode (akin to the complex-number machine modes) that allowed gcc to assign BP components individually to registers, and to pass/return BPs components in registers. This version had space and time overhead of only 75%, and that was without any optimizations to eliminate redundant checks.
This experience leads me to believe that with optimizations to eliminate redundant bounds checks, and with the ability to assign BP components individually to registers, space and time overhead can be brought under 50% (i.e., 1.5x slowdown and 1.5x code size increase).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |