[HN Gopher] Low-Level Software Security for Compiler Developers
___________________________________________________________________
Low-Level Software Security for Compiler Developers
Author : struct
Score : 86 points
Date : 2023-02-18 11:07 UTC (11 hours ago)
(HTM) web link (llsoftsec.github.io)
(TXT) w3m dump (llsoftsec.github.io)
| tptacek wrote:
| This is pretty great; they've done the work to produce useful
| capsule summaries of a bunch of memory safety topics (like
| forward- and backward-edge CFI, JOP, and PAC). Looking forward to
| seeing how far they can take it. The assembler snippets are
| useful and could be fleshed out more.
| staunton wrote:
| The 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.
| ngneer wrote:
| The security industry has a lot of people looking for shortcuts
| or claiming to provide them.
| loup-vaillant wrote:
| > _The vast majority of businesses choose speed over security_
|
| I would add that the vast majority of businesses also choose
| features over speed.
|
| In some cases they pay _lip service_ to speed, for instance by
| choosing C++, but pay zero attention to _actual_ speed, because
| they end up writing in a pointer fest RAII style that destroys
| memory locality and miss the cache all the time. Compared to
| that, even Electron doesn't look too unreasonable.
| pjmlp wrote:
| 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...
| vonimo wrote:
| That 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.
| _a_a_a_ wrote:
| Compilers 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?
| eimrine wrote:
| As far as I've understood the article is about how to fool a
| CPU.
| _a_a_a_ wrote:
| 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.
| hummus_bae wrote:
| From skimming a few pages, it seems to be C-family compilers in
| general.
| tptacek wrote:
| It's a book (in progress), not an article, and it is talking in
| large part about compilers for unmanaged languages.
| JonChesterfield wrote:
| 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 wrote:
| 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 wrote:
| > _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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-02-18 23:01 UTC)