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