Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Low-Level Software Security for Compiler Developers

llsoftsec.github.io

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Low-Level Software Security for Compiler Developers

#11

Post by loup-vaillant »

staunton wrote: post #3

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

Re: Low-Level Software Security for Compiler Developers

#12

Post by tptacek »

_a_a_a_ wrote: post #4

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?

It's a book (in progress), not an article, and it is talking in large part about compilers for unmanaged languages.

Re: Low-Level Software Security for Compiler Developers

#13

Post by tptacek »

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.

Re: Low-Level Software Security for Compiler Developers

#14

Post by MobiusHorizons »

loup-vaillant wrote: post #10
pjmlp wrote: post #6

Earlier quoted context omitted.

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 g…

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.

Re: Low-Level Software Security for Compiler Developers

#15

Post by hummus_bae »

_a_a_a_ wrote: post #4

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?

From skimming a few pages, it seems to be C-family compilers in general.

Re: Low-Level Software Security for Compiler Developers

#16

Post by ngneer »

staunton wrote: post #3

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 security industry has a lot of people looking for shortcuts or claiming to provide them.

Re: Low-Level Software Security for Compiler Developers

#17

Post by wizzard0 »

loup-vaillant wrote: post #10
pjmlp wrote: post #6

Earlier quoted context omitted.

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 g…

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.

Re: Low-Level Software Security for Compiler Developers

#18

Post by WalterBright »

staunton wrote: post #3

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

This is the punishment approach. What it inevitably leads to is denial, coverup, unwillingness to innovate, and not fixing problems because fixing them is an implicit admission of fault.

The better way is for no-fault, encouraging disclosure and openness about bugs, and collaboration in fixing them.

Re: Low-Level Software Security for Compiler Developers

#19

Post by WalterBright »

staunton wrote: post #3

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 vast majority of businesses choose speed over security

The D compiler would be faster if we turned off array bounds checking and assert checking. But we leave those security features turned on for release builds.

Re: Low-Level Software Security for Compiler Developers

#20

Post by rightbyte »

loup-vaillant wrote: post #11
staunton wrote: post #3

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 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 lo…

If they write bad and slow Cpp code surely their Electron code will be even slower?
Post reply on HN