Skip to content

Minutes 15 Aug 2024

Jump to bottom
Paul Albertella edited this page Aug 15, 2024 · 1 revision

Host: Paul Albertella

Participants: Igor Stoppa

Agenda:

  • Goal is to make it easier to access (and link to) documents authored and reviewed by OSEP (and other working groups)

Discussion

  • Igor looking at danger of kernel corruption of stack
    • Some mitigations that are intended to protect against stack-smashing (page canary)
    • Compiler-injected canaries for every function call
    • Both intended to catch ‘linear’ corruption - a sequence of addresses
    • Might not detect spot corruption
  • Paul: Would we not be able to detect misbehaviour at a higher level if the stack is corrupted, though?
  • Treat the entire kernel environment as hostile and untrustworthy?
  • Can we evaluate the degree of uncertainty? Does this help us to
  • Igor: But we cannot prove the correctness of this - or that can be objectively proven to be sufficient
    • Requires that we treat the possibility of a failure as a certainty, and have a mitigation in place for when (not if) this happens
  • What can we do to enable Linux to be used in safety applications, even if we know that we can’t rely on it?
    • Identify the things that can go wrong and explore the set of things we can do to deal with that
    • Start from the foundational principle that Linux cannot be ‘provably correct’
    • Demonstrate that this is true with some examples of corruption
  • Key point: if we devise a strategy for using Linux in safety applications that does not accept its inherent limitations and the unavoidable possibility of failure, then that strategy cannot be sufficiently safe
  • Counter the negative reaction by making the ‘bad news’ verifiable
    • Document the experiment that demonstrates the ‘bad news’
    • Features WG is already engaged in this
    • Establish what mitigations exist and how far they can help
  • Status of PRs
    • Suggest breaking out the ‘Safety-oriented considerations’ sections of PR38 into a separate PR, so that the material based purely on inspection of the code can be landed as a starting point for future work
Clone this wiki locally