Re: Denial of denial of service

[prev] [thread] [next] [lurker] [Date index for 2007/01/29]

From: Yossi Kreinin
Subject: Re: Denial of denial of service
Date: 09:13 on 29 Jan 2007
Martin Ebourne wrote:
> On Sun, 2007-01-28 at 13:44 +0200, Yossi Kreinin wrote:
> 
> Now lets see, this shouldn't be too hard. The key point to remember here
> is that a try block covers a fixed range of code which always resides
> within a given range of machine addresses for any given compilation
> (ignoring PIC here, but that's fixable).
> 
> So what we need are some good old fashioned tables here. Say start
> address, end address, catch handler address, maybe stack offsets and
> other stuff. When the implementation's throw function is called it is
> trivial to unwind the stack and get the program counter in each method
> back up the stack, after all this has to be saved anyway for normal
> operation.

I don't think it does. What does have to be saved is the address right after the 
point of call. The address of destructors needed for unwinding is a different 
address. I guess you could arrange some way to look up the one based on the 
other (using a new-fashioned hash table or something), not the most trivial 
thing to do. PIC code aside, I don't think anyone actually produces hash tables 
at link time.

And there is not always a "canonical" callstack layout (the kind you can parse 
from within the program without knowing how each function was compiled). gcc has 
-fomit-frame-pointer telling it to avoid generating this canonical layout. Green 
Hills does this by default. For each function you'll have to generate a lot of 
code handling each special case of unwinding.

The approach apparently taken by, say, gcc on x86 - adding a dynamically 
maintained unwind stack - has the big advantage of being simple enough to be 
reliable enough.

> 
> No rocket science here I'm afraid.

Lack of rocket science is probably not something to be afraid of...

Let's make it simple: did you actually see it /done/? I tried it with gcc 3.3.1 
on x86 and exceptions do translate to overhead (I don't know x86 assembly 
either, but I can see when 2 additional instructions are emitted). Green Hills 
on ARM is worse, trust me. Let's say I don't care for the monstrous inflation of 
data. Let's say I don't care that the generated assembly code looks like dog 
vomit. Can you name a platform where no extra instructions in the normal flow 
path are generated when exceptions are enabled?

A lot of things are simple, theoretically. Theoretically you can take a huge 
program with no user-specified type information (say, a Scheme program) and have 
a smart compiler figure out the static type constraints wherever they exist and 
generate all the statically-typed implementations at link time, and it's 
constant time, right, since the program size is a constant, right?

I really want to know about a practical platform which handles exceptions well. 
Maybe it does other things which are theoretically possible with C++ but I've 
never seen them done either.
There's stuff above here

Generated at 23:01 on 06 Feb 2007 by mariachi 0.52