As some of you may or may not know by now, I am now employed by the Linux Foundation to help improve Linux security. The primary way that I am doing that is through the work I do for ClangBuiltLinux, of which I am an official maintainer.

Linux kernel patches

First and foremost, I am a Linux kernel developer, meaning that I love sending kernel patches. Getting familiar with git send-email and the standard Linux kernel workflow can be difficult but now that I am used to it, I find other things cumbersome.

Some of the patches that I sent in February are as follows:

  • arm64: Make CPU_BIG_ENDIAN depend on ld.bfd or ld.lld 13.0.0+: I did not do a whole ton of heavy lifting on this, it is mostly thanks to Fangrui Song that this is possible. Getting proper big endian support for AArch64 is not the biggest deal because it is not super common except in networking but more support is more support. One less configuration option that has to be toggled :)

  • qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute: This one is particularly nasty. Indirect function calls through function pointers can be a major security threat in C, where they can be used in ROP chains. Clang’s Control Flow Integrity is a way to guard this, where indirect function calls have their parameters checked to attempt to make sure that the function call has not been hijacked. This support is currently out of tree but patches like this are critical for getting it pushed upstream. This patch fixes a CFI failure in the qemu_fw_cfg driver, where attempting to read the firmware revision will cause the kernel to panic when it is read.

  • Makefile: Remove # characters from compiler string: A report came in that AMD’s Optimzing C/C++ Compiler (AOCC, based on LLVM/Clang) could not build the kernel as it would error out due to the # symbol in the version string (which starts a comment in Make and is required to be escaped). Kconfig does not support escaping # yet so the easiest fix is to just remove that symbol if it is present. AOCC may come in handy later if it has certain optimizations that the kernel can take advantage of

  • drm/i915: Enable -Wuninitialized: -Wuninitialized has become a very important warning over the past year of so because GCC’s version (-Wmaybe-uninitialized) was disabled by Linus in 5.7. i915 maintains a separate set of CFLAGS from the rest of the kernel and this was disabled before -Wuninitialized became smarter in newer LLVM versions so this commit re-enables it. I had this patch locally for a while with another workaround but Arnd Bergmann pointed out that other workaround is no longer necessary so this can be enabled for everyone!

  • drm/amd/pm/swsmu: Avoid using structure_size uninitialized in smu_cmn_init_soft_gpu_metrics: Speaking of -Wuninitialized… here is an instance where it proves useful. Using uninitialized stack memory is never a good idea and can even be a security issue depending on the context. Linux himself pointed this out and accurately explaining that while the default: case never happens, it still should not do this.

Patch review and input

In open source development, patch review is a currency to barter with. In order to have your own patches reviewed quickly, it is in your best interest to review patches quickly yourself. Below are some of the patches that I provided review on, which helps ensure the kernel’s quality. Some of these reviews span multiple messages, which can be viewed at the bottom of the page.

Issue triage and reporting

As a maintainer, it is important to address issues that are reported to you as well as report issues to other people when you do not have the expertise to deal with them yourself. ClangBuiltLinux is at the intersection of three major projects: the Linux kernel, the LLVM compiler collection, and QEMU (as we use it for boot testing the kernels we build in our CI). We work with a few major continuous integration systems such as KernelCI, Continuous Kernel Integration (CKI), and the Oday team from Intel, which results in reports that need to be looked at.

I will not go into too many details but here are some of the issues that I responded to or reported during February.

Tooling patches

ClangBuiltLinux has a few different repos that we maintain to ease our workload. The first of which is the boot-utils repo, which houses a few scripts to make booting the Linux kernels that we build in QEMU easier. QEMU is a rather unwieldy program, as it has a LOT of flags and it is not immediately obvious which ones should and should not be used for testing. We use this locally on our workstations as well as in our continuous integration (more on that in a second). This month I contributed:

To help us easily track regressions in the kernel, we have started relying very heavily on TuxSuite and GitHub Actions for our continuous integration. This month I spent a lot of time trying to get us more coverage of various trees and configurations that have proved problematic in the past. In its current state, ClangBuiltLinux is in the “turning on the lights” phase (starting up), this is a major step in the “keeping them running” phase (stabilizing), and once that is stable, we can focus on adding features and polish as people request them (new development).

I maintain a set of Python build scripts for LLVM and binutils so that people can easily test with the latest versions of these tools in a contained environment (by default, the script does not touch anything outside of the repository). A small set of updates to these this month for improved testing and verification:

Lastly, we have had to ship a couple of QEMU binaries to get access to features that we need for testing or to work around issues with distribution versions of QEMU. The work in this area this month was concerned with the latter. Ubuntu shipped a broken qemu-system-riscv64 binary, which I actually fixed upstream in the 5.0.1 stable series, but Ubuntu misses that fix in a set of security backports to 4.2. I shipped a fixed binary in this repo for our CI, reported the issue to Ubuntu upstream, then reverted it in our repo when it was available.

Conclusion

I hope this has been interesting to follow along with. I am very excited that I get paid to do this full time now. Going foward, I am going to try streaming on Twitch once a week to try and get people involved with Linux kernel development, so that they can see that it is a rewarding path and that it is possible to succeed in it. If you have any questions, feel free to reach out to me using any of the information on my home page!