Re:Bug finding is slow in spite of many eyeballs
by lgunsch on Monday February 23, 2015 @02:37PM
(#9096467)
>we need tools that make development easier, to allow keeping up with the rapidly changing requirements in the software world.
The practice of Test driven development is a great solution to this. The problem is very few people use it, many people actually are against it, and many of those that do do it, do it incorrectly (not on purpose). I would think that small chunks of singly-purposed functionality would be much easier to verify.
Re:Bug finding is slow in spite of many eyeballs
by schoen on Monday February 23, 2015 @06:27PM
(#9097744)
There's kind of a considerable gap between formally verified software and test-driven development, though. For example, a parser or the routines that go into it might pass dozens or hundreds of unit tests, yet still fail to parse certain inputs correctly, fail to parse them in exactly the same way as another parser (as Langsec researchers have emphasized, often producing possible time-of-check/time-of-use vulnerabilities), or even have a memory corruption bug.
I don't mention this in order to criticize test-driven development or the improvements it can bring to software reliability or safety, just to point out that there's still a big gap from there to a formal proof of correctness.
Re:Bug finding is slow in spite of many eyeballs
by jdc on Monday February 23, 2015 @01:40PM
(#9096034)
What are some examples of non-trivial working formally verified software?
Re:Bug finding is slow in spite of many eyeballs
by maemre on Monday February 23, 2015 @05:21PM
(#9097446)
There is Quark [1], a web browser with formally verified kernel. Here, kernel is a process which manages other slave (helper) processes which render the page actually.
Re:Bug finding is slow in spite of many eyeballs
by fdej on Monday February 23, 2015 @01:48PM
(#9096085)
http://compcert.inria.fr/ is the first that comes to mind.
Nonetheless, some of the academic research that has been done on formal verification is quite impressive (including the development of actual nontrivial working software). And it can be done piecemeal -- you could formally certify the functional parts of a crypto library (and demand this standard of future replacements) independently of what goes on in the world of file system drivers.
Realistically speaking, as worse is better, I think a large push for formally verified software probably won't happen for decades to come, but it will happen eventually. It already happened in parts of the hardware industry (Intel certainly don't want the division bug to happen ever again). The main issue is that we need tools that make development easier, to allow keeping up with the rapidly changing requirements in the software world.