Process Separation

[ned14]

@vtnerd

I was nearly convinced that C++ could never produce a bug free program entirely, but yet I keep coming back.

Personally I believe it is impossible to write a bug free program in C or C++ where by impossible I mean that the economics of doing so are not feasible. If you want economically bug free, start with Ada or one of the formal spec languages.

@vtnerd

ned14 said:
Firstly, we exclusively use C++11 which very considerably reduces the attack space over C or legacy C++.

How does it reduce the attack space? Do you mean the additional language features and libraries will reduce the number of bugs that developers write?

It’s mainly the vastly improved STL in C++ 11. Those have been audited for buffer overflow attacks and such, unlike most third party libraries you’d have to fall back onto (e.g. Boost) if you didn’t have them.

I think it was Howard Hinnant who said that Apple’s internal testing had found orders of magnitude improvements in the exploitability of newly written C++ 11 code to the extent that as a general rule you simply shouldn’t write in C any more if you want a secure program. Of course an excellent C programmer will not write insecure C programs, but we’re worried about average programmers here. Average programmers are crap with pointers and managing memory securely. An average programmer need never touch pointers or manage memory in C++ 14, though of course an average programmer won’t know that and will still be manually calling new/delete etc. and using pointers directly.

@vtnerd

And what about all the compiler bugs?

Same goes for an Ada or Haskell compiler. We’re all always at the mercy of toolsets. I’d hazard though that you’ll see fewer bugs using a toolset than hand writing everything in assembler.

@vtnerd

How do you figure? If you compile in C++ mode, you’ll get better type checking than strict C. And you won’t have exceptions. There’s a reason why Go promoted the use of return code and defer statements over C++ style exceptions. You get the RAII without the difficulty of understanding the exception guarantees that a class can provide - recovering from an exception often leads to invalid states in classes.

Little of the Maidsafe code base uses exceptions currently. Longer run we’ll be deploying std::expected<T, E> gather-collapse style gather exception throws to return value collapsing. We’re currently blocked on Visual Studio for std::expected<> though, but expected<> lets you retrofit exception unsafe code very easily.

@vtnerd

ned14 said:
Process separation is of course better again, and in the post launch refactor when we go to work on eliminating some of the eleven memory copies we do between network sockets and the user it will be done in a way where the GPU’s memory could be used to hand off data between privilege separated processes.

Are there going to be calculations done on the GPU?

Of the eleven memory copies, the following could be pushed onto the GPU with huge benefits:

1. SHA512 round.
2. gzip deflate round.
3. AES256 round.
4. XOR round.
5. SHA512 round.

Right now after those the present design requires we bring it back onto the CPU for some Routing processing and then a further AES256 round as part of the RSA encrypt round before it heads out to RUDP for 8Kb chunking. But certainly pushing the above five memory copies onto the GPU should be relatively easy with the current design and which would have enormous effects on mobile device battery life if that device has hardware OpenCL support (right now that’s only the Tegra K1).

Niall