Hacker News Reader

I'll take the bet that in 2035 it's still going to be C/C++ (or a C derivative like Boring C). Because rewriting all that code is an economic impossibility. There's a very long way to go before the rate of foundational Rust code written exceeds the rate of foundational C/C++ code written. And even if you manage to have 100% Rust and 0% C/C++ code being written, you still have a huge legacy to write, which literally costs billions of dollars (ALL operating systems, ALL browsers, ALL interpreters (Python/PHP/Perl/...), ALL compilers (GCC, LLVM), ALL web servers, etc.)

Honestly I think your view of technological adoption is fairly naive -- I don't see much content here other than "everyone get behind Rust!".

IMO the more realistic approach is a systems approach: make it so that badly written C code doesn't completely hose your system. I like the application compartmentalization work (Chrome style, DJB style), and capability work like Capsicum. And LangSec work in making safe parsers. The trusted computing base has to be reduced. Not every line of C code should run in a trusted context!!! Principle of least privilege. We know (or should know) all this stuff.

That is many of orders of less magnitude less work / cost, and I think actually feasible. Coherent and secure systems architecture is more achievable than everybody writing perfect C code or everybody switching to another language.

Another thing the Rust community should be working on is easy and efficient IPC with C programs. So you can rewrite a secure core in Rust and communicate with legacy C/C++ running in an untrusted OS context.

And also fixing the mess that is Linux containers, so it isn't so difficult to secure them (i.e. see Docker's security issues)

I haven't used it yet, but apparently Rust's FFI with C (in both directions) is quite good:

https://doc.rust-lang.org/book/ffi.html

In fact, we removed language features in order to gain a zero-cost interop.

Which ones?

Green threads.

That doesn't do IPC though right? When I say IPC, I mean where you have a Rust process and and a C/C++ process running with different privileges. When people say FFI, they mean Rust code and C code running in the same process.

I thought Chromium had a library for this (for multiple C++ processes), but I guess it is sort of ad hoc now?

https://www.chromium.org/developers/design-documents/inter-p...

https://www.chromium.org/Home/chromium-security/education/se...

https://github.com/pcwalton/gaol

This seems like a great start, but it would be far more useful if there was a C/C++ side. I only see Rust examples, which makes me think it is for Rust <-> Rust communication.

Though it's great to see this, because just rewriting in Rust -- while fantastically expensive -- isn't necessarily enough. You need multiple security measures. The grandparent comment was mistaken about this.

'Honestly I think your view of technological adoption is fairly naive -- I don't see much content here other than "everyone get behind Rust!".'

I think you may not have seen much content because you weren't looking for it very hard; for one thing, you seem to have simply instantiated for me an instance of the fallacy I mentioned. People overestimate change in the short term, but underestimate it in the long term.

"IMO the more realistic approach is a systems approach: make it so that badly written C code doesn't completely hose your system."

We've been doing that for 40 years. Since it is already a sufficient problem that C can hose the process it is in, even perfect process isolation is not sufficient. Building all the protection code in C also has a track record of demonstrated failure. You're basically proposing we continue doing the exact same things that are also the reason we're having this conversation in the first place. If this plan worked, we would not even be here.

I'd also point out that if we're talking track records, capabilities have failed pretty comprehensively to date.

"We know (or should know) all this stuff."

And yet, here we are. Theory says this ought to work. Reality says it isn't. Reality wins.

"Another thing the Rust community should be working on is easy and efficient IPC with C programs. So you can rewrite a secure core in Rust and communicate with legacy C/C++ running in an untrusted OS context."

More evidence that you "didn't see much content" in my post because you weren't looking for it is that I already said that.

Finally, I'm arguing the first derivative and you're arguing the zeroth. I think it's perfectly feasible that much more of the code written in 2035 will be in Rust than in C, and people will look at you funny if you insist on writing a new subsystem in C. If you think that's unthinkable, well, that's the long-term underestimating fallacy I was talking about. Since, as I already mentioned in my post, Mozilla is already starting to do this it's hardly unthinkable that by 2035 everybody will be.

With respect, you clearly read what you pre-judged and expected to read in my post, not what I actually said. If you found that to be "naive", well, I don't think that comes from me.

I shouldn't have been so harsh, because despite the fact that these techniques are already widely deployed [1], most people don't understand them. In fact I had a conversation with an ffmpeg developer on this forum and he didn't think securing ffmpeg this way was feasible. And I think another reply to my message mistook FFI for IPC, as you did. So the vocabulary hasn't even trickled down to most programmers.

Application compartmentalization is certainly difficult in practice, and should be made easier, but it is deployed and it's a lot easier than rewriting all code in a different language.

ffmpeg is a great example. It is hideously broken, with thousands of likely security bugs [2]. Now let's compare these two strategies:

    1) Rewrite EVERY video codec in Rust
    2) Reuse existing code, but run it in a completely
    untrusted process (no OS privileges), and only 
    communicate with IPC.

The claim is that #2 is much more achievable than #1. You could say that #1 takes orders of magnitude more work, which is true, but that doesn't even quite capture it -- it actually scales differently because for #2 you do constant work and get security for ALL video codecs. It's O(1) vs O(n).

Why not get secure foundations by 2025 instead of 2035? What I'm arguing for is a hybrid, heterogeneous architecture -- instead of rewriting 100% of code in Rust, rewrite 5% in Rust and isolate the remaining 95%. That gets you a better result which much less effort.

These techniques predate modern browsers -- they are used in qmail and djbdns. [3] [4]

I agree with the idea that most people underestimate change in the long term, but that is orthogonal to my point -- we get get secure systems faster with a different technique, in a shorter time frame.

Also, if you look at the code we're using today, it is perfectly reasonable to conclude that in 2035 we will be using a lot of the same code. People are still using Linux (1991), GNU tools (started in the 80's), Python (1990), Perl (1985), PHP (90's), etc. In 2035 is undoubted we will be using code from 2015 -- in fact it is likely we will be using code from 1985 in 2035. Those are the economics of software. Stable code is extraordinarily valuable and long lasting.

But the good news it that we can be running C code from 1985 in 2035 and still have secure systems!

I apologize for saying your post was naive, but I can tell from your original post and response that you haven't worked with security or operating systems very much. I have some impatience because the "rewrite everything" response reminds me of people who think they can rewrite an old codebase do better, when in reality they would end up with something worse [5]. There is a lack of subtlety and lack of understanding implied when you want to start completely from scratch.

Browsers like Firefox and Chrome didn't even start from scratch. Firefox was derived from decades-old netscape code, and Chrome reused Webkit, which was derived from Konquerer. Google has infinite money, but didn't rewrite Android from scratch -- it is based on Linux and hundreds of other open source projects. Code lasts A LONG TIME -- simply suggesting that everyone rewrite it is not helpful. It's an economic impossibility.

[1] Deployed by code you are using every day: (Chrome, Firefox, IE, Safari, etc.)

https://en.wikipedia.org/wiki/Process_isolation

http://www.chromium.org/developers/design-documents/multi-pr... https://developer.mozilla.org/en-US/Firefox/Multiprocess_Fir...

[2] https://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and...

[3] http://cr.yp.to/cv/activities-20050107.pdf -- see "extreme sandboxing".

[4] http://cr.yp.to/qmail/qmailsec-20071101.pdf

[5] http://www.joelonsoftware.com/articles/fog0000000069.html

Reghr came to a Bay Area Rust Meetup long ago, we're all generally fans of his work. :)

I love the ideas behind Rust. I don't think it can replace C for all use-cases.

C has the use-case of zero-dynamic-allocations. AFAIK, Rust is not very compatible with that mode of use.

As far as I know, C and Rust give you the same opportunities to work with stack-allocated values.

It's not just stack allocations, it's support for intrusive allocations, pointers not always conforming to simple ownership semantics, etc.

Huh? If you don't want any dynamic allocation (or any other features that require support from a runtime system), you can use `#![no_std]` and instead use `libcore` directly. This is how the standard library itself is implemented.

The problem, as I understand it, is that Rust's ownership semantics don't accommodate for the kinds of programming needed by 0 dynamic allocations.

Lots of intrusive nodes pointing freely at one another, is an example. I've heard some Rust libraries approximate intrusive allocations almost perfectly, but not quite perfect.

As long as you're willing to use unsafe, you can write things exactly as you can as in C. That's of course, not as satisfying as not needing to, but by encapsulating that in a library and providing a safe interface, downstream users still get the benefits.

Can a safe interface always be provided?

I can't say that I'm able to speak to every single possible program ever, but at _some_ level, it should end up safe, yeah.

Rust's ownership and borrowing rules are entirely a compile-time thing: they just determine what objects can be safely used, and when. There is absolutely no need to use dynamic allocation to benefit from Rust's ownership and borrowing checks. And none of the other core language facilities (primitive types, unsafe pointers, fixed-size arrays) require dynamic allocation either.

What does require dynamic allocation is using boxed objects and dynamically sized collections (such as vectors and tree maps), which are provided by `libstd`, but not by `libcore`. Think of using `libcore` as using C or C++ in freestanding mode.

As far as I know, nobody managed to create a comprehensive intrusive data structure library that behaves as optimally as in C, due to the ownership semantic restrictions.

So just bypass the ownership checks, with `unsafe`. It gives up on memory safety, but you still keep all the other benefits of a modern language: algebraic data types, pattern matching exhaustiveness checks, parametric polymorphism, etc. So, even when writing `unsafe` code, Rust is strictly superior to C and C++.

Also, I would contend that, for the vast majority of programs, the benefits of a simple, hierarchical, statically enforceable resource management scheme like RAII outweigh the downsides. Programs that need more sophisticated approaches are a very small minority.

Actually I think you are being rather timid in your proposal. C is the symptom: the cause is the underlying Von Neumann machine. The future is hardware - re-configurable hardware connected as needed for the present purpose.