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/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:10 EST