www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OffTopic]: Safer usage of C++ in Chrome

reply Paulo Pinto <pjmlp progtools.org> writes:
Nothing new to those of us that are aware of the issues that 
plague C and C++ codebases in terms of security, still kind of 
interesting to see how much effort is being thrown at trying to 
fix Chrome's security exploits.

https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub

Naturally what many usually forget, is that all those development 
hours and bug fixes translate into salaries and contracting rates 
that need to be paid.

Unfortunely the marketing of how much development costs one saves 
by using languages like D, still don't reach most finance 
departments.
Sep 09
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 9 September 2021 at 07:28:00 UTC, Paulo Pinto wrote:
 Nothing new to those of us that are aware of the issues that 
 plague C and C++ codebases in terms of security, still kind of 
 interesting to see how much effort is being thrown at trying to 
 fix Chrome's security exploits.

 https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub

 Naturally what many usually forget, is that all those 
 development hours and bug fixes translate into salaries and 
 contracting rates that need to be paid.

 Unfortunely the marketing of how much development costs one 
 saves by using languages like D, still don't reach most finance 
 departments.
Thanks for link. Most of the problem that are described are indeed fixed by D (minus implementation bugs, so in theory). So temporal safety is solved with escape analysis and safe, space safety with bounds checks, UFA is solved by the GC, use of unitialized memory is solved by default initialization, etc... Trivial question. Do I undestand correctly this sentence ?
 Of these 2 types of safety, spatial safety is relatively easier 
 to achieve ... (For example, you have to perform the array 
 bounds check, which might cost more than not doing it.
without intention to offend the author, is it supposed to mean something as absurd as "checking bounds might cost more than not checking them because you have to check them" ?
Sep 09
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Salaries are offset by the job market, no? Some people mistakenly 
believe that language properties matter more than the job market, 
but even from purely technical perspective, how do you plan to 
run all that web 2.0 stuff?
Sep 09
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/9/21 3:28 AM, Paulo Pinto wrote:
 Nothing new to those of us that are aware of the issues that plague C 
 and C++ codebases in terms of security, still kind of interesting to see 
 how much effort is being thrown at trying to fix Chrome's security 
 exploits.
 
 https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIu
WZLt5kVeH9e9jXv/pub 
 
 
 Naturally what many usually forget, is that all those development hours 
 and bug fixes translate into salaries and contracting rates that need to 
 be paid.
 
 Unfortunely the marketing of how much development costs one saves by 
 using languages like D, still don't reach most finance departments.
Surely, porting Chrome to D would cost more... Where it might cost less is if you used a memory-safe-oriented language like D or Rust at the start. -Steve
Sep 09
parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 9 September 2021 at 11:46:20 UTC, Steven 
Schveighoffer wrote:
 On 9/9/21 3:28 AM, Paulo Pinto wrote:
 Nothing new to those of us that are aware of the issues that 
 plague C and C++ codebases in terms of security, still kind of 
 interesting to see how much effort is being thrown at trying 
 to fix Chrome's security exploits.
 
 https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub
 
 
 Naturally what many usually forget, is that all those 
 development hours and bug fixes translate into salaries and 
 contracting rates that need to be paid.
 
 Unfortunely the marketing of how much development costs one 
 saves by using languages like D, still don't reach most 
 finance departments.
Surely, porting Chrome to D would cost more... Where it might cost less is if you used a memory-safe-oriented language like D or Rust at the start. -Steve
Yes, my monetary point was about what languages get chosen when starting new projects. This document outcome is that porting is not an option given the amount of existing code. Even on Android, they are doing baby steps, only replacing the bluetooth stack. D like in low level capabilities, since version 7.
Sep 09
prev sibling next sibling parent Elronnd <elronnd elronnd.net> writes:
On Thursday, 9 September 2021 at 07:28:00 UTC, Paulo Pinto wrote:
 Nothing new to those of us that are aware of the issues that 
 plague C and C++ codebases in terms of security, still kind of 
 interesting to see how much effort is being thrown at trying to 
 fix Chrome's security exploits.
99% of security bugs in browsers are due to JIT. That's not something a language like d would help with. There was some work done on formally verified JIT, but it's wildly complex and difficult to work with. GC is similar—you want a GC which is attuned to JS's semantics, not just to piggyback off of D's GC, because D gc is not precise nor concurrent.
Sep 09
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/9/2021 12:28 AM, Paulo Pinto wrote:
 Nothing new to those of us that are aware of the issues that plague C and C++ 
 codebases in terms of security, still kind of interesting to see how much
effort 
 is being thrown at trying to fix Chrome's security exploits.
 
 https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIu
WZLt5kVeH9e9jXv/pub 
"For example, Chromium already uses -fno-exceptions" Momentum seems to be building behind the idea that exception handling is the wrong path.
Sep 09
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 9 September 2021 at 23:57:43 UTC, Walter Bright 
wrote:
 Momentum seems to be building behind the idea that exception 
 handling is the wrong path.
Google has always had their set of esoteric rules including this one.
Sep 09
parent reply max haughton <maxhaton gmail.com> writes:
On Friday, 10 September 2021 at 00:02:36 UTC, Adam D Ruppe wrote:
 On Thursday, 9 September 2021 at 23:57:43 UTC, Walter Bright 
 wrote:
 Momentum seems to be building behind the idea that exception 
 handling is the wrong path.
Google has always had their set of esoteric rules including this one.
If I'm not mistaken they do allow exceptions in new code now, their famous no exception policy was mostly due to them being stuck with old design decisions.
Sep 09
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 10 September 2021 at 01:03:58 UTC, max haughton wrote:
 If I'm not mistaken they do allow exceptions in new code now, 
 their famous no exception policy was mostly due to them being 
 stuck with old design decisions.
Right. There's a bad habit among people to say "well company X does this therefore it must be smart for us too", but often company X does it because of some problem specific to their codebase/organization/product which ought not be applied generally. I'd note the remainder of that document doesn't mention exceptions at all, so there's no way to evaluate the reasoning behind that one mention. It almost certainly is related to their pre-existing internal condition.
Sep 09
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/9/21 9:24 PM, Adam D Ruppe wrote:
 On Friday, 10 September 2021 at 01:03:58 UTC, max haughton wrote:
 If I'm not mistaken they do allow exceptions in new code now, their 
 famous no exception policy was mostly due to them being stuck with old 
 design decisions.
Right. There's a bad habit among people to say "well company X does this therefore it must be smart for us too", but often company X does it because of some problem specific to their codebase/organization/product which ought not be applied generally.
I once was in charge of maintaining code that targeted a small microprocessor. The person who first set up the build didn't know how to make the linkfile work with parameters, so it was C code, with *all parameters* passed via global variables (why a compiler linkfile would be able to mess this up is beyond me). It was a long time before I figured it out, and the code base still had all the parameters as globals. But in actuality, the code the compiler generated for it was so horrendous, I kept global variables in all but the most trivial cases. It was an 8-bit CPU in a 16-bit address space, with only 8K of code ROM space, so every little bit (literally) counted. 16-bit math was to be avoided at all costs, so no pointers. For sure, local constraints can dictate why code is written in a weird way. -Steve
Sep 10
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 10/09/2021 11:57 AM, Walter Bright wrote:
 Momentum seems to be building behind the idea that exception handling is 
 the wrong path.
What I'm interested in atm is weather open-ended exceptions with stack unwinding is the wrong way to go. Super simple question but I am starting to be of the belief that this is wrong. We need stronger compiler guarantees with compiling backed checks. Something like this: Basically every functions gets attributed with a __throws attribute, inferred based upon what it calls, what it catches and what it throws. Structs only that get moved not copied, with a guarantee that it'll be caught before the thread ends and the stack will unwind due to using regular return's. What drew me to this is my colorimetry library. I do need compiler guaranteed caught exceptional handling, but I don't want the user to wiggle out of it by using return values. The problem is exceptions need classes and the runtime handling. But I want it to work with -betterC (mixing compiler versions with shared libraries, yeah that won't end well). With this, I *might* be able to work my way up to a full GUI toolkit. This is the big missing piece right now. ```d struct NullPointerException { string message; string moduleName; int lineNumber; this(string message, string moduleName = __MODULE__, int lineNumber == __LINE__) { this.message = message; this.moduleName = moduleName; this.lineNumber = lineNumber; } } void doSomething() /* __throws() */ { State* state = newState; try { state.someComplexProcess(); } catch (scope ref NullPointerException npe) { // ... stuff here } // scope void[NullPointerException.sizeof + size_t.sizeof] __exceptionStorage; // state.someComplexProcess(__exceptionStorage[]); // if ((cast(size_t*)&__exceptionStorage[0]) == 1 && scope ref NullPointerException npe = *(cast(NullPointerException*)&__exceptionStorage[size_t.sizeof])) { // // ... stuff here // } } void someComplexProcess(State* state, /*scope void[] __exceptionStorage */) /* __throws(NullPointerException) */ { Process process; process.add(libFunc(state, /* __exceptionStorage */)); } int libFunc(State* state, /*scope void[] __exceptionStorage */) /* __throws(NullPointerException) */ { if (state is null) { throw NullPointerException("State cannot be null"); // if (__exceptionStorage.length < NullPointerException.sizeof + size_t.sizeof) // assert(0); // (cast(size_t*)&__exceptionStorage[0]) = 1; // *(cast(NullPointerException*)&__exceptionStorage[size_t.sizeof]) = NullPointerException("State cannot be null"); // return ReturnType.init; } return 0; } ```
Sep 09
parent Kagamin <spam here.lot> writes:
On Friday, 10 September 2021 at 00:15:17 UTC, rikki cattermole 
wrote:
 What I'm interested in atm is weather open-ended exceptions 
 with stack unwinding is the wrong way to go.
Nobody ever said that unhandled exceptions are a way of error handling, it's a bug that terminates the program. By design exception is a mechanism that delivers error information from the error diagnostic location to the error handling location, it's not intended to fly into the sunset.
Sep 12
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/9/2021 12:28 AM, Paulo Pinto wrote:
 Nothing new to those of us that are aware of the issues that plague C and C++ 
 codebases in terms of security, still kind of interesting to see how much
effort 
 is being thrown at trying to fix Chrome's security exploits.
 
 https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIu
WZLt5kVeH9e9jXv/pub 
This is a good summary of unsafe usage, and a guide for us in making D safer.
Sep 09