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

21–23 of 23 posts

Re: Low-Level Software Security for Compiler Developers

#21

Post by loup-vaillant »

rightbyte wrote: post #20
loup-vaillant wrote: post #11

Earlier quoted context omitted.

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

It depends. The main reasons C++ code can be slow are costly abstractions (don't laugh!), inappropriate data structures, and pointer fest (that leads to cache misses).

Writing the same program in JavaScript won't change much of the above. You'll have the JIT overhead for sure, but the basic data structures will remain relatively efficient, and if you're starting out with a pointer fest it won't be any worse in JavaScript. As for the GUI itself, well… I expect it'll be as fast as any browser.

Re: Low-Level Software Security for Compiler Developers

#22

Post by staunton »

WalterBright wrote: post #18
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 col…

> What it inevitably leads to is denial, coverup, unwillingness to innovate

... and finally adoption of the required methods and reaching required standards, like countless cases of successful regulation since times immemorial.

How do you give companies a positive incentive to fix an issue if the issue does not cost them money? Fixing such an issue is a competitive disadvantage.

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

What does that look like? Paying companies per disclosed bug in their software? State sponored white-hat hacker teams that find and fix the companies' bugs for them without disclosure? I can't think of anything that sounds realistic.

Re: Low-Level Software Security for Compiler Developers

#23

Post by WalterBright »

staunton wrote: post #22
WalterBright wrote: post #18

Earlier quoted context omitted.

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

> What it inevitably leads to is denial, coverup, unwillingness to innovate ... and finally adoption of the required methods and reaching required standards, like countless cases of successful regulation since times immemorial. How do you give companies a positive incentive to fix an issue if the issue does not cost them money ? Fixing such an issue is a competitive disadvantage. > The better way is for no-fault, enc…

> What does that look like?

The D Language Foundation operates that way, for a real world example. The bug list is open, anyone can /view/comment on/submit a fix/ for any bug.

> Fixing such an issue is a competitive disadvantage.

Fixing problems is an advantage, not a disadvantage.

Post reply on HN