Consider section on run-time vulnerabilities in compilers?

[sam-ellis]

Consider whether run-time vulnerabilities in compilers themselves are within the scope of the book. For example, with compilers used in JITs or run via automated CI farms with possibly hostile input then there exists a possibility to use the compiler an an attack vector to break onto the wider machine that the compiler is running on.

[kbeyls]

I indeed think this is in scope. I'm interested to hear what @g-kouv thinks about this.

[g-kouv]

I agree that this is in scope!

We were already planning to include special sections on JITs, since there are special considerations (common bugs, exploit techniques and mitigations) that are relevant to JIT compilers. In particular, we were initially planning for a section in the memory vulnerabilities chapter, since the most common exploits fit in that area. Of course, other types of vulnerabilities (like side-channels) also apply to JITs, and we should mention them where appropriate.

An alternative structure could see JITs getting their own chapter (after all the relevant types of vulnerabilities have already been discussed). I think we could defer any decision on changing the the structure towards a separate chapter, for when we've got at least some of the already planned content in mind, though.

Regarding automated CI farms, I think we're going into more "generic" security territory rather than something specific to compilers, since mitigation of the risks seems to me to be more about setting up the CI (I'm thinking of compiler explorer-type services) rather than doing something differently when developing the compilation tools themselves (which will likely not be controlled by whomever is setting up the CI). But there's perhaps something we can say about the level of trust that should be placed in compilation tools? There is an intersection with supply chain attacks (#45) here.