Minutes 23 Oct 2025

Host: Paul Albertella

Participants: Pete Brink, Daniel Krippner, Victor Lu, Igor Stoppa

Agenda

- The Supply Chain perspective (continued)

- Avoiding the 'Philosophy' trap

Igor: When we talk about supply chain we normally use this in the sense of security. Knowing where something has come from doesn’t tell me if it’s good. This is a first requirement, but it’s not everything.

Pete: Provenance may tell you who the supplier is, which may imply some level of ‘due diligence’, and give you some assurance that it is what it is claiming to be

Igor: What is the value that you are gaining by this?

Victor: Supply chain can be both a safety and a security concern: https://www.splunk.com/en_us/blog/learn/vulnerability-vs-threat-vs-risk.html

Igor: For the kernel, we can argue that (up to a point) the kernel is tested, so we can argue that this testing has some value - albeit potentially with a different configuration, toolchain, etc

Paul: The question is can we take any credit or derive any value from the testing that has been undertaken upstream? Or if I repeat those tests in my context, with my toolchain, can I derive value from that?

Igor: This is like approximating a function - there are variables involved that may have an unknown effect. This is why use of qualified toolchains is necessary - so that you can be confident that the outputs of a compiler are as specified by the applicable standard.

Pete: Qualification in safety is about effectiveness in detection of errors

Paul: What if I want to rely on Linux to have verified its function as a generic operating system component, and have effective processes for detecting and resolving bugs in that context. It is verified in a wide variety of contexts and systems - this diversity is its strength

Igor: Perhaps, but the most widely deployed contexts and use cases are Android phones or servers in the cloud. This means that certain categories of bugs are unlikely to be encountered, and if we want to use Linux in a different context (e.g. a car) then we must consider whether there is any equivalence with this.

Pete: Is there any true unit testing in Linux?

Igor: Some but this is very variable, and may be done by individual contributors. e.g. by device drivers. But looking at functionality that is ‘core’ the testing can be re-used in different contexts. And some are - e.g. cryptographic functions - because they have no state

Paul: It’s difficult to do this at a per-function level for everything, because of the nature of the software.

Pete: Arguably we could restructure the functions to enable unit testing.

Paul: My goal is to make it possible for software projects such as Linux (and Linux specifically) to refine or extend their software development practices to make my life easier, not because I say they must but because it makes their life easier or better.

Victor: Asking what is the difference between AI safety and AI security might give us some idea about what is the difference in the context of the kernel.

Igor: The key difference with the kernel is the intent of an attacker, seeking to exploit a vulnerability - which may be associated with a relatively rare, but predictable event.