Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #4711 > unrolled thread

Research to Create Automated Buffer Overflow Protection

Back to article view | Back to comp.programming

Contents

  Research to Create Automated Buffer Overflow Protection Heidi Brayer <hap1026@gmail.com> - 2014-08-26 09:11 -0700
    Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 18:54 +0200
      Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-26 18:16 +0100
        Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 19:35 +0200
          Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-26 18:59 +0100
            Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 21:26 +0200
              Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-26 20:33 +0100
                Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 21:50 +0200
                  Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-26 21:41 +0100
                    Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 10:21 +0200
                      Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-27 10:27 +0100
                        Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 11:51 +0200
          Re: Research to Create Automated Buffer Overflow Protection Melzzzzz <mel@zzzzz.invalid> - 2014-08-26 20:39 +0200
            Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-26 20:13 +0100
            Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 21:38 +0200
              Re: Research to Create Automated Buffer Overflow Protection Melzzzzz <mel@zzzzz.com> - 2014-08-26 23:11 +0200
                Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 09:50 +0200
                  Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-27 10:16 +0100
                    Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 12:15 +0200
                    Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-27 14:40 +0100
              Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-27 10:13 +0100
                Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 14:06 +0200
              Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-27 10:32 +0100
                Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 12:14 +0200
          Re: Research to Create Automated Buffer Overflow Protection "Chris M. Thomasson" <no@spam.invalid> - 2014-08-26 14:06 -0700
        Re: Research to Create Automated Buffer Overflow Protection Melzzzzz <mel@zzzzz.invalid> - 2014-08-26 20:16 +0200
          Re: Research to Create Automated Buffer Overflow Protection Öö Tiib <ootiib@hot.ee> - 2014-08-30 09:20 -0700
    Re: Research to Create Automated Buffer Overflow Protection Jongware <jongware@no-spam.plz> - 2014-09-15 10:47 +0200
      Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-09-15 10:46 +0100

Page 2 of 2 — ← Prev page 1 [2]

#4729

Dmitry A. Kazakov wrote:

> Someone, *not* the customer, must pay for the faults.

The customer is the only participant pumping any money into the system, 
therefore one of the following must hold:

a) there is no system (no software is written)
b) the customer pays for faults as they occur
c) the customer pays upfront to cover the costs of liability insurance (or 
whatever)

What I think you are trying to say is that if the cost of faults is properly 
factored into the whole equation (however that's achieved), the customers will 
prefer to buy from suppliers who use safer languages because they'll be able to 
deliver at a lower price.  That may be true, but there are many other factors 
to consider (such as speed of development, flexibility of development, 
execution speed, power consumption....)

I don't think the market is that efficient myself.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#4736

On Wed, 27 Aug 2014 10:13:24 +0100, Chris Uppal wrote:

> Dmitry A. Kazakov wrote:
> 
>> Someone, *not* the customer, must pay for the faults.
> 
> The customer is the only participant pumping any money into the system, 
> therefore one of the following must hold:
> 
> a) there is no system (no software is written)
> b) the customer pays for faults as they occur
> c) the customer pays upfront to cover the costs of liability insurance (or 
> whatever)

The customer pays for fault prevention, which may be in the form of an
insurance. But when a fault happens, it is for the vendor to pay.

> What I think you are trying to say is that if the cost of faults is properly 
> factored into the whole equation (however that's achieved), the customers will 
> prefer to buy from suppliers who use safer languages because they'll be able to 
> deliver at a lower price.  That may be true, but there are many other factors 
> to consider (such as speed of development, flexibility of development, 
> execution speed, power consumption....)

I don't think the customer should be directly interested or involved in any
aspects of the developing process. It is an indicator that there is much
wrong with the system if the customer is interested in these, as most
paying customers are.

Regarding resource consumption, why should the customer be any interested
in that? They are merely application constraints, once satisfied, there is
no whatsoever economical reason to push them further.

In fact, it is usually the government which tries to push us buying
electrical bulbs we don't want to buy, and forbidding vacuum cleaners we
liked to buy from the market.

> I don't think the market is that efficient myself.

But the only other tool is governmental control and oversee, which is much
worse than market in any aspect. The biggest problems with the non-existing
market is vendor lock; unfair competition when one product like a compiler,
OS etc is funded from selling unrelated products like office software;
no-warranty licenses, and the very idea of "intellectual property" that you
don't own the software you bought.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4732

Dmitry A. Kazakov wrote:

> Languages should be chosen according to their technical merits and
> software quality must be the most important one.

Why ?  Sound flat-out false to me.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#4734

On Wed, 27 Aug 2014 10:32:58 +0100, Chris Uppal wrote:

> Dmitry A. Kazakov wrote:
> 
>> Languages should be chosen according to their technical merits and
>> software quality must be the most important one.
> 
> Why ?  Sound flat-out false to me.

Because of the role the software will play in short future and because of
the nature of software which is different to one of physical systems.

In a physical system potential damage is bounded by spatial constraints and
the energy level at which the system operates. In a software system, at
least, in the systems designed in the ways they are designed now, the
effect of a fault is practically unbounded. A buffer bounds violation is a
good example of how an allegedly minor and localized fault of changing a
few memory bytes may cause whatever effect on the whole system.

It is only a time before we will experience very serious accidents caused
by the software and severity will only increase.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4725

> "Dmitry A. Kazakov"  wrote in message 
> news:1n77920ibcpbp.wgyjm4i9snuc.dlg@40tude.net...
> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
> > The only ways to get rid of C, in decreasing order of severity are:
> >
> > (a) catastrophic global war, pestilence, or famine;
> > (b) legislation of an alarmingly authoritarian nature;
> > (c) the provision of an even more powerful language that is even more 
> > prone
> > to being abused.

> (d) liability to the damages caused by software faults.

[...]

http://www.stroustrup.com/JSF-AV-rules.pdf

;^) 

[toc] | [prev] | [next] | [standalone]

#4716

On Tue, 26 Aug 2014 18:16:47 +0100
Richard Heathfield <invalid@see.sig.invalid> wrote:

> 
> If you add bounds-checking to C (which is what we're talking about,
> really), (a) you discover eventually that people have already done
> it, and (b) bounds-checking imposes a performance penalty that at
> least some people are not prepared to tolerate.

For example take scimark2 in "go" language:
with bounds checking
 bmaxa@maxa:~/examples/go/src/github.com/bmaxa/sci$ go build -o scimark2
bmaxa@maxa:~/examples/go/src/github.com/bmaxa/sci$ time ./scimark2
**                                                              **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov)     **
**                                                              **
Using       2.00 seconds min time per kernel.
Composite Score:         1060.91
FFT             Mflops:   933.39    (N=1024)
SOR             Mflops:  1235.80    (100 x 100)
MonteCarlo:     Mflops:   179.01
Sparse matmult  Mflops:  1485.93    (N=1000, nz=5000)
LU              Mflops:  1470.43    (M=100, N=100)

real	0m34.279s
user	0m34.232s
sys	0m0.055s
without:
bmaxa@maxa:~/examples/go/src/github.com/bmaxa/sci$ go build -o scimark2 -gcflags -B
bmaxa@maxa:~/examples/go/src/github.com/bmaxa/sci$ time ./scimark2
**                                                              **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov)     **
**                                                              **
Using       2.00 seconds min time per kernel.
Composite Score:         1231.16
FFT             Mflops:  1177.07    (N=1024)
SOR             Mflops:  1258.24    (100 x 100)
MonteCarlo:     Mflops:   168.89
Sparse matmult  Mflops:  1702.12    (N=1000, nz=5000)
LU              Mflops:  1849.46    (M=100, N=100)

real	0m30.569s
user	0m30.531s
sys	0m0.046s

It is 20% faster without bounds checking !



-- 
Click OK to continue...

[toc] | [prev] | [next] | [standalone]

#4742

On Tuesday, 26 August 2014 21:16:34 UTC+3, Melzzzzz  wrote:
> On Tue, 26 Aug 2014 18:16:47 +0100
> Richard Heathfield <invalid@see.sig.invalid> wrote:
> 
> > If you add bounds-checking to C (which is what we're talking about,
> > really), (a) you discover eventually that people have already done
> > it, and (b) bounds-checking imposes a performance penalty that at
> > least some people are not prepared to tolerate.
> 
> For example take scimark2 in "go" language:
> with bounds checking

...

> It is 20% faster without bounds checking !

If there was particular goal to improve bounds checking in industry
then we would have "fat" pointers on hardware level already.

Hardware could trap on out-of-bounds accesses and so a software
with loose logic could only contribute to DOS attack, not to other
security preaches. 

In fact the 64 bits (that lot of architectures use as address size) 
is sort of large size for to be entirely useful for addressing 
memory so perhaps that bound checking could be implemented without
further enlarging the pointers.

[toc] | [prev] | [next] | [standalone]

#4768

On 26-Aug-14 18:11 PM, Heidi Brayer wrote:
> According to a 2013 report examining 25 years of vulnerabilities (from 1998 to 2012) ..

That period does not span "25 years". I hope this first sentence is not 
typical for the rest of the research project.

[Jw]

[toc] | [prev] | [next] | [standalone]

#4770

Jongware wrote:

> On 26-Aug-14 18:11 PM, Heidi Brayer wrote:
>> According to a 2013 report examining 25 years of vulnerabilities (from
>> 1998 to 2012) ..
> 
> That period does not span "25 years". I hope this first sentence is not
> typical for the rest of the research project.

Ah, play nice. It's only ten years out. If the subject were archaeology, 
you'd be amazed at the precision.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.programming

csiph-web