Low-Level Software Security for Compiler Developers
llsoftsec.github.io
Low-Level Software Security for Compiler Developers
1–10 of 23 posts
Re: Low-Level Software Security for Compiler Developers
#2There's a tension here.
Emitting 'secure' code almost always means emitting 'slower' code, and one of the few things compilers are assessed on is the performance of the code they generate.
Compilers are built as a series of transformation passes. Normalisation is a big deal - if you can simplify N different patterns to the same thing, you only have to match that one canonical form later in the pipeline.
So if one pass makes code slower/secure, later passes are apt to undo that transform and/or to miss other optimisations because the code no longer looks as expected.
So while it is useful to know various make-it-secure transforms, which this book seems to cover, it's not at all obvious how to implement them without collateral damage.
On a final note, compiler transforms are really easy to get wrong, so one should expect the implementation of these guards to be somewhat buggy, and those bugs themselves may introduce vulnerabilities.
Re: Low-Level Software Security for Compiler Developers
#3The vast majority of businesses choose speed over security and avoid investing in security since they can offload the cost of incidents to their users. One of the main reasons such "more secure tools" projects are interesting for users is that they provide an easy and cheap avenue towards claiming an effort towards security was made and avoiding liability. On one hand, such tools actually help make things secure, on the other hand, speed and ease of use (not security) being the top priorities, the effect is probably limited. People who care much more about security than average would not start a new project in C/C++ to begin with and where legacy code is involved, dealing with it is hard enough already without trying to "make it secure".
The only way to really improve the level of security in the industry is to assign responsibility and damages to those who fail to implement it. So far, it seems all market participants are content with 90% of security concerns being addressed by security theater.
Re: Low-Level Software Security for Compiler Developers
#4Compilers are an interest of mine so I'll read the article later, but I'm curious whether this is talking about C variety compilers which are generally unsafe, or compilers for managed languages which should never emit code allowing attacks (for some definition of 'never'). Which of these is this article/book discussing?
Re: Low-Level Software Security for Compiler Developers
#5The vast majority of businesses choose speed over security and avoid investing in security since they can offload the cost of incidents to their users. One of the main reasons such "more secure tools" projects are interesting for users is that they provide an easy and cheap avenue towards claiming an effort towards security was made and avoiding liability. On one hand, such tools actually help make things secure, on…
This is thankfully changing.
Returns in digital stores, increasing visibility of how it actually costs in real money to fix those issues, warranty clauses in consulting gigs (usually free of charge), and introduction of cyber security laws like in Germany [0].
[0] - https://www.bsi.bund.de/EN/Das-BSI/Auftrag/Gesetze-und-Veror...
Re: Low-Level Software Security for Compiler Developers
#6There's a tension here. Emitting 'secure' code almost always means emitting 'slower' code, and one of the few things compilers are assessed on is the performance of the code they generate. Compilers are built as a series of transformation passes. Normalisation is a big deal - if you can simplify N different patterns to the same thing, you only have to match that one canonical form later in the pipeline. So if one pas…
1960's systems were already taking security first approach and the industry would have kept down that route if it wasn't for UNIX and C adoption.
IBM even did their RISC research in PL.8 taking into consideration safety and pluggable compiler infrastructure, similar to what people nowadays know from LLVM approach.
Some would say that security measures in the car industry also slow drivers down and are a nuisance.
Re: Low-Level Software Security for Compiler Developers
#7That was an excellent read. I look forward to enjoying their section on JIT compiler vulnerabilities, a whole fascinating topic in itself, when it is completed.
Re: Low-Level Software Security for Compiler Developers
#8Compilers are an interest of mine so I'll read the article later, but I'm curious whether this is talking about C variety compilers which are generally unsafe, or compilers for managed languages which should never emit code allowing attacks (for some definition of 'never'). Which of these is this article/book discussing?
As far as I've understood the article is about how to fool a CPU.
Re: Low-Level Software Security for Compiler Developers
#9Compilers are an interest of mine so I'll read the article later, but I'm curious whether this is talking about C variety compilers which are generally unsafe, or compilers for managed languages which should never emit code allowing attacks (for some definition of 'never'). Which of these is this article/book discussing?
As far as I've understood the article is about how to fool a CPU.
Hardly that, is about corrupting a state to take control. The CPU just does what it's told (not true, halfway down it starts on Covert channels and side-channels which are a different thing entirely).
On the 1st half, I'm uncertain how it relates to compilers.
Re: Low-Level Software Security for Compiler Developers
#10There's a tension here. Emitting 'secure' code almost always means emitting 'slower' code, and one of the few things compilers are assessed on is the performance of the code they generate. Compilers are built as a series of transformation passes. Normalisation is a big deal - if you can simplify N different patterns to the same thing, you only have to match that one canonical form later in the pipeline. So if one pas…
1960's systems were already taking security first approach and the industry would have kept down that route if it wasn't for UNIX and C adoption. IBM even did their RISC research in PL.8 taking into consideration safety and pluggable compiler infrastructure, similar to what people nowadays know from LLVM approach. Some would say that security measures in the car industry also slow drivers down and are a nuisance. htt…
> Some would say that security measures in the car industry also slow drivers down and are a nuisance.
Not sure about that: what are brakes for? Slowing down & stop, right? But then I ask, how fast would you drive if your car had no brakes? I would guess not very fast at all. Thus, one important role of breaks is to allow you to drive faster.
In practice, the more safety measures you put, the more confident people grow and the faster they drive. To a point, of course.
Same with programming: I prototype faster with a good static type system than I do with a dynamic one. One reason is that I just write fewer tests (including those one-off verifications in the REPL).