[JonChesterfield]

There'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.

[pjmlp]

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.

https://en.m.wikipedia.org/wiki/Unsafe_at_Any_Speed

[loup-vaillant]

> 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).

[MobiusHorizons]

I think you are thinking about the wrong type of security measures. I believe the op is talking about features like traction control, stability control, and ecu features that prevent engine power and braking at the same time. In performance driving situations (eg track driving) it is standard practice to disable these for the best track times. As safety features on the road they make a lot of sense, but can get in the way during high performance driving.

[wizzard0]

A fire alarm at home is important, a fire alarm in the chimney or the engine cylinder makes it unusable.

Exploit mitigations do work, but

a) compiler /does not/ know what are you building and what are your requirements

b) they only protect from /specific, known/ threats the same way a generic fire alarm won't protect you from CO leak or an electric shock.

c) but they waste time, energy and RAM whether they are relevant or not

The only way to get systems that are secure, performant and easy to maintain is to invest in tools that make it easier for developers and users (!) to analyze what the system actually does. Not trying to make everything "magically secure".

Pretending a microwave with Super Safety Cat Detector is a Magic Pasta Heater will only end up with lawsuits from owners of dead hamsters - and rightfully so, because it's trying to defraud and dumb down users instead of educating them.