Spectre and the end of langsec
Spectre has nothing to do with program correctness or safety. It has everything to do with <i>hardware&#x27;s</i> correctness and safety.<p>That is, the basic premise of hardware process isolation is that a process cannot have any knowledge of what another process is doing, or whether it even exists, unless it is explicitly permitted (e.g. the OS offers an API to look at processes).<p>This basic premise is now broken: enough information leaks via timing as to allow to read arbitrary memory regions. It&#x27;s like you built a house laying bricks in a formally correct way, but the walls proved to be permeable because the bricks themselves have a flaw.<p>Since this flaw is not fundamental, that is, not even every currently existing processor exhibits it, it appears to be reasonable to replace the flawed design of the bricks, and not to re-engineer house construction.<p>There is a nice quote in the article, about doing basic science to find out how software (and hardware) <i>actually</i> works, since specs are badly incomplete. It can be matched with another, earlier famous quote: &quot;Beware of this code; I only proved it correct, I did not test it.&quot; Black-box testing of information systems is not going anywhere, formal methods or not; at the very least, we need evidence that formal methods were not visibly mis-applied, and also evidence that other basic premises, like those of hardware, still hold. Because sometimes they don&#x27;t.