The recent furore around University of Minnesota’s “Hypocrite commits” research, which spilled over from the Linux Kernel Mailing List and into mainstream tech media, has provoked a lot of discussion about the Linux kernel community’s processes, and arguably provided ammunition to folks who have been saying all along that open source software cannot be trusted.
Over in the ELISA community, which is exploring how to use Linux in safety-critical systems, it was even suggested that this incident demonstrates that, for Linux to be fit for use in a safety application, the kernel process would need to be redefined and coding standards enforced.
For myself, I continue to believe that open source projects deliver software that is as good as, and often better than, proprietary initiatives. A key difference is that the mistakes and breakages happening behind closed doors often go unreported, and the participants learn less as a result.
I expect that the kernel community will continue to learn, and will evolve its processes in response to this and other events over time. And I totally understand Greg KH’s decision to revert all commits in response to the incident, not least because it signals that action must and will be taken when trust is lost.
But thinking about the use of Linux and open source in a safety context, it seems to me this situation only confirms something that we already know:
- complex software generally has bugs
- some bugs are likely to slip through whatever process is in place to catch them
It would be extremely naive to think that bad actors haven't already introduced bugs or vulnerabilities into widely used software.
Equally it would be wildly optimistic to hope that software at the scale and complexity of Linux could ever be considered bug-free, or completely deterministic, or 100% “safe”, or 100% “secure”.
For engineers thinking about how to use Linux or similarly complex software in safety critical applications, I suggest that the lesson here is not “We need to enforce coding standards and change the process to make the software fit for safety”.
I think it would be much more realistic to say:
“We expect occasional bugs in Linux (or any large-scale software). Our safety design recognises that, and our mitigations aim to minimise the risk of harm arising when bugs occur.”
And as a postscript… it now looks as though the claims of the researchers were fiction all along. In light of this, we can highlight a further benefit of the open source approach. This has all played out in the glare of public scrutiny, with the evidence visible to all parties. As a result we can all consider what happened and learn from it.
Download the white paper: Safety of Software-Intensive Systems From First Principles
In this white paper, Paul Albertella and Paul Sherwood suggest a new approach to software safety based on Codethink's contributions to the ELISA community and supported by Exida. Fill the form and you will receive the white paper in your inbox.
Related blog posts:
- Applying functional safety techniques to complex or software-intensive systems: Safety is a system property, not a software property >>
- Open source and Safety at Codethink: Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney >>
Other Articles
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Introducing Interrogizer: providing affordable troubleshooting
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- My experience of the MIT STAMP workshop 2020
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Improving RISC-V Linux support in Rust
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- The Case For Open Source Software In The Medical Industry
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Engineering's jack of all trades: an intro to FPGAs
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Codethink open sources part of staff onboarding - 'How To Git Going In FOSS'
- Getting into open source
- How to put GitOps to work for your software delivery
- Open Source Safety Requirements Analysis for Autonomous Vehicles based on STPA
- Codethink engineers develop custom debug solution for customer project
- Codethink contributes to CIP Super Long Term Kernel maintenance
- Full archive