Kernel hacking behind closed doors

The recent hardware security vulnerabilites exposed the kernel community to unprecedented restrictions and bureaucrazy. Pure software bugs which only affect the Linux kernel are a completely different category and the kernel community has established and well working ways to handle them.

Hardware issues like Meltdown, Spectre, L1TF etc. must be treated differently because they usually affect all Operating Systems and therefore need coordination across different OS vendors, distributions, hardware vendors and other parties. For some of the issues, software mitigations can depend on microcode or firmware updates, which need further coordination.

Meltdown/Spectre hit all affected parties completely unprepared, which was nicely reflected in the resulting chaos all over the place. With that experience the kernel community started to push for workable scenarios to handle these kind of issues as it was entirely clear to everyone that this was just the start and the tip of the iceberg.

This talk will take a look at the difference between hardware and software vulnerabilities, gives insight into the events  surrounding Meltdown/Spectre and explains how the later issues, e.g. L1TF, have been dealt with. It also looks at the approach the kernel community has taken to further reduce the annoyance for future issues of that kind