Re: We have met the enemy, and the enemy is ... you.

["Halvar Flake" <HalVar () gmx de>]

The trouble with detecting int overflows is that the compiler would
have to know in which situations an int overflow is not acceptable.
Look at an MD5 implementation and imagine there being an exception
for each additive integer overflow. Ouch. 

Also, compilers do not always use "ADD" for addition or "MUL" for
multiplication -- for small powers of two, we abuse the CPUs address
calculation unit to do the arithmetic for us, and that has the side
effect of not setting flags.

Cheers,
Halvar

> --- Ursprüngliche Nachricht ---
> Von: jnf <jnf () nosec net>
> An: Michael Spath <michael.spath () gmail com>
> Kopie: dailydave <dailydave () lists immunitysec com>
> Betreff: Re: [Dailydave] We have met the enemy, and the enemy is ... you.
> Datum: Thu, 13 Apr 2006 18:51:05 -0700 (PDT)
>
> > INTO would trigger an interrupt (which one depends on the OS) only
> > when the OF flag is set, which does not cover all integer overflows.
> > To handle all int overflows you also have to check the carry flag,
> > so a JO/JC pair looks like a much better solution to me.
>
> INTO generates int 4, the first 32 interrupt vector numbers are reserved
> by intel, so it doesn't vary per OS. When I mentioned INTO/BOUND I was
> mostly just using them as examples. I fail to really understand why we do
> not make use of certain features of the underlying hardware that would
> solve a lot of these problems.
>
> For instance, in regards to int overflows, nearly every
> (perhaps all of them?) architecture supports the ability to detect int
> overflow, however I do not see compilers making really any use of this.
>
> I suppose as someone pointed out that BOUND is horrible on performance, I
> haven't bench marked it so for the moment at least I will take their word
> on it, this provides the only real explanation that satisfies thus far.
>
>
> > For high security people can use the ADA language, which adds
> > by default run-time checks for boundaries and integer overflows
> > (and more).
>
> We could also stop writing programs or start using carrier pidgeons, etc.
> While I generally agree with you the premise wasn't to try to get the
> world to switch its primary programming languages, but rather just to
> investigate why we have some fairly complex solutions to problems that the
> underlying hardware already has fixes for.
>
> > regards,
> > --spath

-- 
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer