News for hackers. Stuff that matters.
Re:The CompCert C Compiler by lisper on Sunday May 26, 2024 @03:49PM (#40484822)
A cautionary tale for anyone relying on formal proofs of correctness:

https://spinroot.com/spin/Doc/rax.pdf

TL;DR: in the 1990s NASA flew an autonomous control system that was formally verified, tested out the wazoo, but which nonetheless failed in flight.

[UPDATE] I did not mean to imply that the formal verification failed. It did not. The formal verification worked as advertised. The cause of the failure was much more subtle and nuanced.

Re:The CompCert C Compiler by elteto on Sunday May 26, 2024 @03:58PM (#40484872)
You make it seem like the formal verification missed an issue. Not quite what happened:

"The first effort consisted of analyzing part of the RA autonomous space craft software using the SPIN model checker. One of the errors found with SPIN, a missing critical section around a conditional wait statement, was in fact reintroduced in a different subsystem that was not verified in this first pre-flight effort. This error caused a real deadlock in the RA during flight in space."

The model actually found an issue that was later reintroduced in a different part of the system that was not formally verified. If anything, it tells us we need _more_ formal verification!

Re:The CompCert C Compiler by lisper on Sunday May 26, 2024 @04:09PM (#40484970)
> You make it seem like the formal verification missed an issue.

Sorry, that was not my intent. I added a clarification.

Re:The CompCert C Compiler by sobkas on Sunday May 26, 2024 @09:28PM (#40486837)
> > You make it seem like the formal verification missed an issue.

> Sorry, that was not my intent. I added a clarification.

I'm sorry but it didn't. Without reading next comment I wouldn't know why it failed.

Re:The CompCert C Compiler by cwzwarich on Sunday May 26, 2024 @04:04PM (#40484926)
I’m confused. Wasn’t the error actually in an unverified subsystem and isomorphic to an error caught by the model checker in a verified subsystem? Isn’t this more of a cautionary tale for someone not relying on formal verification?
Re:The CompCert C Compiler by lisper on Sunday May 26, 2024 @04:08PM (#40484953)
> Wasn’t the error actually in an unverified subsystem and isomorphic to an error caught by the model checker in a verified subsystem?

No, it was quite a bit more subtle than that. The problem was that there was no mechanism to enforce the use of the formally verified API, and an application programmer put in a direct call to a system function that bypassed that API.

Source: I was the technical lead on the RAX executive.

Re:The CompCert C Compiler by extrabajs on Sunday May 26, 2024 @04:28PM (#40485130)
It sounds more like a cautionary tale against bypassing APIs. What part of this is related to formal verification?
Re:The CompCert C Compiler by Quekid5 on Sunday May 26, 2024 @04:38PM (#40485186)
This is why friends don't let friends use unsafePerformIO ... or whatever the equivalent was here :)

I'm still a bit confused about the point though. I feel like an adequate rejoinder would be to enforce formal methods at all the levels? I'm obviously not talking specifics (because I don't know them! ... and you do), but this seems like a failure of process or lack of enforcement of formal methods "all the way down" as it were. I dunno, color me confused...

Re:The CompCert C Compiler by wucke13 on Sunday May 26, 2024 @06:48PM (#40486106)
Which almost reads as a cautionary tale about mechanisms like Dust's `unsafe`. Not necessarily the specifics of the Rust, but the overall idea of having a safe (by whatever means) sunset of operations and and additional unsafe operations, which eases code analysis tremendously. You can't got without unsafe in most embedded systems. But it's good to very explicitly mark in the code wherever the unknown depths of UB lurk if not the most attention is exercised.
Re:The CompCert C Compiler by renox on Monday May 27, 2024 @02:41PM (#40493388)
While this is true, let's not forget that if there's a problem in the unsafe section, the issue can manifest itself much later in the safe code.. I'm not a Rust programmer but I remember reading about such kind of issue (an alignment error if memory serves).

So sometimes you can build a 'self contained' unsafe part made safe with the right API but not always, which is already a significant improvement over other languages which are unsafe all the time..

Re:The CompCert C Compiler by tombert on Sunday May 26, 2024 @06:54PM (#40486144)
Honestly, I don't think you're wrong, and this is from a guy who is getting a PhD in formal methods.

Formal methods are super cool, and formal verification is even cool, but it can be really easy to think it's always perfect. It gives you such amazing guardrails most of the time that it can be easy to stop looking for when there aren't any.

For example, model checking is cool and useful, but sort of by definition it is exhaustive and as a result you end up having to restrict scope in a lot of cases (For example, redefining the INTEGERS set to {-1000...1000} in TLA+). This is almost always perfectly fine and can catch a lot of weird cases, but it's easy to forget that "nearly everything" is not the same thing as "everything".

Obviously I still think formal methods are worth it, but they're not a substitute for being careful.

Re:The CompCert C Compiler by lisper on Sunday May 26, 2024 @08:58PM (#40486686)
> formal methods are worth it, but they're not a substitute for being careful.

Yes. Exactly this. I hereby dub this Tombert's law. :-)

Re:The CompCert C Compiler by tombert on Sunday May 26, 2024 @09:15PM (#40486768)
I'm honored! I always thought Tombert's Law would end up being something about cartoon trivia, so this is much better.
Re:The CompCert C Compiler by lisper on Sunday May 26, 2024 @09:17PM (#40486782)
I'm going to start listing it alongside my other favorite aphorism: Furious activity is no substitute for understanding. -- H.H. Williams
Re:The CompCert C Compiler by aidenn0 on Monday May 27, 2024 @12:09AM (#40487480)
IIRC Regehr found a bug when testing compcert. It turned out to be a bug in a standard header file. Similar idea of bugs due to incomplete verification.