Software That Fixes Itself
Page 2 of 2
For seven of the attacking team’s approaches, ClearView created patches that corrected the underlying errors. In all cases, it discarded corrections that had negative side effects. On average, ClearView came up with a successful patch within about five minutes of its first exposure to an attack.
“What this research is leading us to believe is that software isn’t in itself inherently fragile and brittle because of errors,” says Rinard. “It’s fragile and brittle because people are afraid to let the software continue if they think there’s something wrong with it.” Some software engineering approaches, such as “failure-oblivious computing” or “acceptable computing,” share this philosophy.
ClearView “is a really good starting point,” says Yuanyuan Zhou, a professor of computer of science at the University of California, San Diego, who also researches software dependability. Zhou lauds the evaluation process the researchers used for the project but says she wants to see ClearView tested on a wider variety of applications.
“Keeping the system going at all costs does seem to have merit,” adds David Pearce, a senior lecturer in computer science at Victoria University in Wellington, New Zealand. He points out that ClearView is designed to apply patches whenever it detects that something has gone wrong. Some systems are designed to shut down when an error is detected, but if an attacker’s goal is sabotage, Pearce says, this approach plays right into their hands.
But ClearView’s approach could result in some hiccups for the user, Pearce adds. For example, if a Web browser had a bug that made it unable to handle URLs past a certain length, ClearView’s patch might protect the system by clipping off the ends of URLs that were too long–preventing the program from failing, but also preventing it from working fully. However, such issues probably wouldn’t be outright harmful. “It’s generally only hackers that attempt to exploit such loopholes,” says Pearce, “and they would be the ones who suffered.”
Pages
Thank you for ...
Close ×Making the Decision: Understand the hidden costs of embedded design
When designing an embedded system choosing which tools to use often comes down to building a custom solution or buying off-the-shelf tools.
12 comments. Share your thoughts » 0 comments about this story. Start the discussion »