[TUHS] A fuzzy awk.
Lawrence Stewart
stewart at serissa.com
Tue May 21 12:54:36 AEST 2024
Good to learn more of the history! I wonder when the technique got started on the hardware side?
I wouldn’t be surprised if IBM were doing some of this for the S/360 since it was a nearly
compatible set of systems.
-L
> On May 20, 2024, at 10:47 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> I think the title might go to my OS prof, Bart Miller. He did a paper
>
> https://www.paradyn.org/papers/fuzz.pdf
>
> that named it that in 1990.
>
> On Tue, May 21, 2024 at 11:56:30AM +1000, Rob Pike wrote:
>> Ron Hardin was doing this to Dennis's C compiler in the 1980s, well before
>> 1998. And I believe Doug McIlroy was generating random regular expressions
>> to compare different implementations. It's probably impossible to decide
>> who invented fuzzing, so the credit will surely go to the person who named
>> it.
>>
>> -rob
>>
>>
>> On Tue, May 21, 2024 at 12:09???AM Serissa <stewart at serissa.com> wrote:
>>
>>> Well this is obviously a hot button topic. AFAIK I was nearby when
>>> fuzz-testing for software was invented. I was the main advocate for hiring
>>> Andy Payne into the Digital Cambridge Research Lab. One of his little
>>> projects was a thing that generated random but correct C programs and fed
>>> them to different compilers or compilers with different switches to see if
>>> they crashed or generated incorrect results. Overnight, his tester filed
>>> 300 or so bug reports against the Digital C compiler. This was met with
>>> substantial pushback, but it was a mostly an issue that many of the reports
>>> traced to the same underlying bugs.
>>>
>>> Bill McKeemon expanded the technique and published "Differential Testing
>>> of Software"
>>> https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTestingForSoftware.pdf
>>>
>>> Andy had encountered the underlying idea while working as an intern on the
>>> Alpha processor development team. Among many other testers, they used an
>>> architectural tester called REX to generate more or less random sequences
>>> of instructions, which were then run through different simulation chains
>>> (functional, RTL, cycle-accurate) to see if they did the same thing.
>>> Finding user-accessible bugs in hardware seems like a good thing.
>>>
>>> The point of generating correct programs (mentioned under the term LangSec
>>> here) goes a long way to avoid irritating the maintainers. Making the test
>>> cases short is also maintainer-friendly. The test generator is also in a
>>> position to annotate the source with exactly what it is supposed to do,
>>> which is also helpful.
>>>
>>> -L
>>>
>>>
>>>
>
> --
> ---
> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
More information about the TUHS
mailing list