Meltdown and Spectre mitigations — a February update

1. It seems to me that the Clang Static Analyzer would be an excellent tool to do this, if only it could parse the kernel. There has been excellent work on compiling the kernel with Clang/LLVM (as described in a talk at the last LLVM Developers' Meeting [1] and here on LWN [2]), but I'm not aware of efforts to do analysis on the kernel (would love to hear if anybody is working on this!).

In particular, the Clang Static Analyzer preserves the AST of the language, whereas many comparably powerful tools first convert the program into some lower-level intermediate representation. The IR is usually better for implementing proper static analyses, but for ``pattern-matching'' cases like this one, you really do want the original AST.

I'm not sure if GCC has softened their position on allowing the AST to be exported to help static analysis tools, text editor autocompletion, and other use cases; but if they have not, then here is one more argument that they really should. We're compiling the kernel with GCC, and it would be really excellent to dump the kernel's AST for cases like this.

2. I contribute to a static analyzer which does convert program code into IR. However, the particular use case in the article does seem to be fairly easy to recover from IR. Is it really just: "flag the locations where the access of an array is guarded by a bounds check for that access"? I would be interested in exactly what pattern is needed (the article does not elaborate), and what trouble Coverity has had (Coverity isn't very good, but this seems quite simple, so I wonder about the nature of the false positives they're reporting and whether I could do any better). Does anybody have pointers to discussion about this or other relevant information?

[1] https://www.youtube.com/watch?v=6l4DtR5exwo
[2] https://lwn.net/Articles/734071/