
Fuzzing: On the Exponential Cost of Vulnerability Discovery [pdf] - luu
https://mboehme.github.io/paper/FSE20.EmpiricalLaw.pdf
======
cjbprime
Just thought I'd drop a note that the second author (Brandon Falk) streams
development of his full OS fuzzing hypervisor in Rust on Twitch, have been
watching it some.

[https://twitch.tv/gamozo](https://twitch.tv/gamozo)

~~~
thephyber
edit: it looks like his Twitter alias does have an unbanned Twitch account[1]
that has posted recently.

As of March 5, 2019 a Twitter user with that name claims to have been banned
from Twitch and moved to YouTube.

It looks from a YouTube video, he was live-streaming a RE of a game to cheat
(which Twitch and YouTube both may see as ToS violations).

[1] [https://twitch.tv/gamozo](https://twitch.tv/gamozo)

~~~
gamozolabs
Oopsies, yep, I got banned making Maplestory cheats with Ghidra when it came
out.

Nevertheless, I got unbanned and I still stream at:
[https://www.twitch.tv/gamozo](https://www.twitch.tv/gamozo) I upload all the
vods at:
[https://www.youtube.com/user/gamozolabs](https://www.youtube.com/user/gamozolabs)

Hope y'all enjoy the content <3

------
zozbot234
As some might say, there are two ways of building software: Make it simple
enough that there are obviously no bugs, or make it so complex that there are
no obvious bugs. The latter choice is the most common by far.

~~~
cjfd
Such a tired saying. Software that is 'simple enough that there are obviously
no bugs' can not have much more functionality than 'Hello world'. Once upon a
time when software development was still a young field there was the illusion
that software could be written in such a way that every part of the software
was easily inspectable for bugs. In this age we should have learned a long
time ago that this is in fact not the case for all but the most limited
functionality.

~~~
throwaway_pdp09
I'll take a stab and say, despite having not met him, that tony hoare is
probably not witless or naive.

In this he was referring to simplicity in implementation, and simplicity in
the final product where achievable (AKA don't over-ask).

I've worked with a guy that, given a choice, would pick the most complex and
extreme way of doing things. I've also met plenty of manager types who will
elaborate a simple functional and useful 90% product into monster with
repeated scope creep, and who's going to say no to them?

Another relevant Hoare quote for exactly this:

"There is nothing a mere scientist can say that will stand against the flood
of a hundred million dollars. But there is one quality that cannot be
purchased in this way — and that is reliability. The price of reliability is
the pursuit of the utmost simplicity. It is a price which the very rich find
most hard to pay."

KISS, or do you disagree with that too?

~~~
cjfd
I completely agree with the KISS principle and do indeed have to note that it
is very often not followed. Much of the software out there could be simpler.

But even if it were simpler one would not arrive at the point where the
software is so easily understandable that there are obviously no bugs. You may
need to implement, say, the rules of chess. This would be simpler if there was
no castling and no en passant rules but the programmer does not get to decide
the rules of chess and, hence, merely a library for implementing the rules of
chess might not be so simple that it can easily be inspected for bugs. It
certainly won't be that simple if you also take into account the rules of
repeating the same position three times or the fifty move rule. Much of the
software that is used in practice has to still do quite a few things more
things than are needed for the rules of chess so it has not chance whatsoever
to be at the point where all of the bugs are easy to spot.

~~~
throwaway_pdp09
In implementation terms there are simple ways and unnecessarily complex ways
of doing things. As per my 1st post.

In product terms there are definitely things that get pushed in that have no
value, and that happens when there's too much cash around (hence "It is a
price which the very rich find most hard to pay"). An actual example, a 'big
data' project I was involved in. Loadsa big data software thrown at a pile of
hardware. End result, fuck all of worth because it barely ran. A simpler
system would have been a single decently configured and provisioned server
which would have run so much faster (and cost a tiny fraction of the behemoth
we actually built).

I take your point about chess though. I think with a little discussion (time
for which I guess neither of us have) we could come to an understanding and
quite likely an agreement.

