Re: Thou shalt have no other gods before the ANSI C standard

From: Tom Linden (tom_at_kednos.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 05:29:02 -0800

On Sun, 27 Feb 2005 23:48:42 -0500, Trevor L. Jackson, III
<tlj3@comcast.net> wrote:

> David Wagner wrote:
>
>> Trevor L. Jackson, III wrote:
>>
>>> I propose a run-time analysis rather than a static analysis.
>> One potential challenge with run-time analysis is ensuring sufficient
>> coverage. It might be very easy to miss bugs that are triggered only
>> on certain code paths.
>
> No, that is not a problem. The entire theory of validation is that in
> one run of the validation software you can encompass the full complement
> of the possible execution paths.

I don't think that is realistic. Most people take a probabilistic
approach,
claiming nn% coverage.
>
> You are probably thinking of that fact that in a single execution of a
> routine containing a if() {statement_set_1} else {statement_set_2} only
> one of the two sets of statements is executed. But in a full validation
> the close of the else scope triggers a merger of the two sets of
> resulting states.
>
>> I don't rule out the possibility that one could
>> build a tool that is useful nonetheless, but it might take some work.
>
> Definitely. This is not a weekend project. ;=)
>
>>
>>> There is no way I would aim to detect all bugs. But I would be happy
>>> to detect all possible writes to red memory.
>> A simplistic version of this is simply to run the program with bounds
>> checking enabled during testing, and if any bound is ever violated
>> (during
>> the testing phase), then you've got a pretty good idea that the program
>> is likely to be buggy. Unfortunately, that is unlikely to be enough,
>> because for many buffer overruns, it is not at all easy to come up with
>> the test case that triggers the buffer overrun.
>> But, if you can build a tool that detects the presence of code which
>> could write to red memory on some input (potentially other than the
>> input currently being processed), that might address the coverage
>> problem.
>
> The inputs have to be described in terms of their range of possible
> values. That usually means the full set of states of the data type.
>
>> My favorite research work in this direction is the following paper:
>> Eric Larson and Todd Austin, "High Coverage Detection of
>> Input-related Security Faults", Usenix Security 2003.
>> http://fac-staff.seattleu.edu/elarson/security.pdf
>> Personally, I thought this was one of the most exciting ideas in
>> security
>> during the year of 2003. I suspect continued work on some direction
>> like this might well be worth the effort.
>
> Thanks for the reference.
>
> /tj3 

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Quantcast