Remember the Blue Screens?

Oct 27 2006

By Jim Reavis (jim@reavis.org)

In the grand scheme of things, software engineering is a relatively new, yet very complex discipline. Major commercial software applications and even some proprietary internal applications have millions of lines of code. With so much code, the law of averages seems to ensure that a certain amount of bugs are always going to reside in our software, some having severe security ramifications. Some people balk at even describing the discipline as software engineering, saying that it lacks many of the underlying foundations, rules and boundaries of other traditional engineering disciplines. Certainly we can agree that software is developed in many different ways, with varying degrees of compliance with best practices and standards.

Given the complexity of software and the continuous information insecurity headlines we see, it is worthwhile to ask if any progress is being made in developing more secure software. We asked this question at a recent Secure Software Forum dinner in Pittsburgh, and we were reminded of some good news by no less an authority than Dr Bill Scherlis, a professor from Carnegie Mellon University.

Dr Scherlis is the director of Carnegie Mellon’s Institute for Software Research International as well as the PhD Program in Software Engineering. Dr Scherlis reminded us that we do have a long way to go to improve software quality. However, he did say that progress has been made in the last 5 years, and it is very tangible. Do you remember the Blue Screens of Death? Those wacky BSODs (Blue Screen Of Death) certainly cost me a few days rebuilding spreadsheets, recreating word processing documents from scratch and having to download (legally) my 80’s music collection over again. If you are still plagued by the dreaded Blue Screen, you probably are still a heavy user of Windows NT and might not have done much upgrading recently.

As Dr Scherlis explained, the once common Blue Screen of Death was primarily caused by third party device drivers behaving poorly. Unfortunately, the published standards for coding device drivers were not exacting and these device drivers were not certified for the operating system. Into this difficult environment entered SLAM. SLAM is a Microsoft research project to create a knowledge base of tools and whitepapers to improve software quality. One key deliverable has been a static driver verifier, a tool that validates the interfaces and operation of software drivers through source code analysis. Drivers must be certified by this tool before being included in the shipping operating systems. The result? We have replaced draconian blue screens that turn the user a shade of purple with more uptime, or in the worst case a more benign application stop that does not render the whole system unusable.

Approaching zero defect software is a far destination, perhaps an unreachable one. However, the long journey to this destination is yielding benefits along the way. I look forward to the progress the industry makes over the next 5 years.

http://research.microsoft.com/slam/ - The SLAM toolkit checks safety properties of software without the need for user-supplied annotations or abstractions.

http://www.cs.cmu.edu/~wls/ - Home page of Bill Scherlis

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.