LWN: Comments on "Herman: Shipping Rust in Firefox"

Herman: Shipping Rust in Firefox

ras — Fri, 22 Jul 2016 04:02:02 +0000

I've come here to thank tialaramex for his post. It's right up there with the best of the articles on LWN.

Rust for safety

pizza — Thu, 21 Jul 2016 18:11:25 +0000

Most of my experience with MSVC was with C, not C++, and it wasn't until VS2015 that it finally supported C99 *syntax* sufficiently well to be able to use C99 at all on a cross-platform codebase.

Anyway. Back to Rust.

Rust for safety

Cyberax — Thu, 21 Jul 2016 17:54:44 +0000

Back in 2003, MSVC was _better_ than C++ standard. For me the major advantage was that it didn't require template code to be littered with "typename" statements.

Rust for safety

pizza — Thu, 21 Jul 2016 11:45:46 +0000

FWIW, that interview was from 2008 -- And when he says "It's getting very good actually both in terms of standard conformance and in code quality," the implication is that it had a reputation for not being either.

MS's C++ compiler _was_ by far the worst when it came to standards compliance and bugs -- not necessarily in the compiler itself, but also the standard [template] libraries that everyone's supposed to be able to rely on. It's quite a lot better now.

Meanwhile.

"...and deep in GNU C++ you find quite a few non-standard features. Whenever I can, I prefer to deal with ISO standard C++ and to access system-specific features through libraries with system-independent interfaces."

One of the nice things about the GNU toolchain is that you can disable all of those non-standard extensions by using compiler flags to force strict compliance (--std=c++03 --pedantic-errors) and still have a useful compiler. (And GCC doesn't provide any access to "system-specific features", beyond the mandated contents of the standard C/C++ libraries...)

Rust for safety

HelloWorld — Thu, 21 Jul 2016 10:10:50 +0000

> Secondly, he is employed at Microsoft, a company that has a shockingly bad C++ "compiler" (MSVC), notorious for being full of bugs and severely lacking in standards compliance.
It's one of the better implementations according to Bjarne Stroustrup.
https://www.simple-talk.com/opinion/geek-of-the-week/bjar...

Rust for safety

HelloWorld — Thu, 21 Jul 2016 09:43:21 +0000

> For example, we already know it rules out practically all use of global variables
Banning shared mutable state seems entirely reasonable to me.

Herman: Shipping Rust in Firefox

farnz — Wed, 20 Jul 2016 09:12:54 +0000

It's not even guaranteed to be called in Java; it's called if the GC determines that this object has no references and is thus eligible for collection.

In practice, this means that if your process exits before the GC decides that your object is ready for collection, the finalizer is not called at all - e.g. because there happens to have been no memory pressure between the object being allocated, and the process exiting cleanly for a restart.

Herman: Shipping Rust in Firefox

Cyberax — Wed, 20 Jul 2016 07:01:36 +0000

> In Java, you could clean up in the finalize() function.
No, you can not. Finalize method is only guaranteed to run some time in future - like next hour or next day.

The way to manage resources in Java now is try-with-resources statement.

Herman: Shipping Rust in Firefox

oever — Wed, 20 Jul 2016 06:55:41 +0000

If I have a temporary directory, I might like it to be cleaned up no matter how the function exits (except things like poweroff, abort() or SIGKILL; not much anyone can do there).

In C++, you can clean up in the destructor of an object. This is simple RAII. In Java, you could clean up in the finalize() function. The C++ destructor is called immediately when the scope ends. finalize() is called by the garbage collector which runs a few times per second. In Java and C# most variables are pointers to objects and Java does not have a way to automatically call a function directly when the last pointer to an object leaves scope and neither does C#.

A refreshing aspect of Rust is that the syntax for dealing with objects is nice and safe. It has the best of both worlds: no need for manual memory deallocation but the ability to run any type of cleanup when the last reference to an object leaves scope. Defining a destructor is optional and done via the Drop trait.

Herman: Shipping Rust in Firefox

mathstuf — Tue, 19 Jul 2016 20:37:36 +0000

I'm more thinking where there's a directory I created that should not persist outside of the function which created it; claiming ownership of files which already exist would probably not use such an RAII object the same way. `TempDir foo = TempDir::new()` versus `TempDir bar = TempDir::take(path)`.

Herman: Shipping Rust in Firefox

Wol — Tue, 19 Jul 2016 19:37:15 +0000

> If I have a temporary directory, I might like it to be cleaned up no matter how the function exits (except things like poweroff, abort() or SIGKILL; not much anyone can do there). Currently, I have to explicitly try/catch or try/else for this to happen since the language doesn't let me use its memory management facilities for any other resource.

Which language is that? I remember (in the early 80s) using Fortran77 and getting exactly the functionality you're after (except it was buggy :-) The Ops staff swore at me because I accidentally deleted several important files before I realised what was happening and they had to restore them from backup ... :-) (You could declare a file as temporary, and it was deleted on close. The problem was, if you re-used that file descriptor, it ignored any attempt to declare the new file permanent, and deleted that on close, too :-)

The problem with programs is they like to open files anywhere. If they followed the standards and opened temporary files in /tmp, or c:\temp, or wherever they were supposed to, then the operating system would clean up behind them (any real OS that is, I don't think WinDos does it properly).

Cheers,
Wol

Herman: Shipping Rust in Firefox

excors — Tue, 19 Jul 2016 16:57:01 +0000

At the bottom level of language (/language runtime) implementation, dynamically-allocated memory is just a limited resource provided by the OS from sbrk/mmap syscalls. Similarly, file descriptors are a limited resource provided by the OS from open syscalls. Same for threads, GPU memory, network sockets, etc. Why should dynamically-allocated memory get so much more special treatment than any of those other resources that look so similar? (And that's before looking at resources provided by other processes rather than the OS.)

Garbage collection is simulating a computer with an infinite amount of memory. There are some languages that simulate a computer with a near-infinite capacity for threads, using green threads etc, but many don't. In theory a language could probably simulate support for an infinite number of file descriptors, but in practice they never seem to bother - if you try to open ~1024 files they'll happily return a "too many open files" error and let you solve the problem yourself. (Sometimes they'll go part way by GCing file objects to close ones they know can never be accessed in the future, but that only really works in languages with a refcounting GC or with RAII, and if you might access those files again then you're left to manually implement some pooling scheme yourself, so the language still isn't helping as much as it could.)

Nowadays virtual address space pretty much is infinite, and the cost of physical memory seems to still be decreasing exponentially, but many of the other limited resources have remained constant for ages. So I think an exclusive focus on managing memory is not good enough for a modern language - they really ought to assist with managing those other resources just as well.

Herman: Shipping Rust in Firefox

mathstuf — Tue, 19 Jul 2016 15:57:25 +0000

If I have a temporary directory, I might like it to be cleaned up no matter how the function exits (except things like poweroff, abort() or SIGKILL; not much anyone can do there). Currently, I have to explicitly try/catch or try/else for this to happen since the language doesn't let me use its memory management facilities for any other resource. Why can't I just have an object which cleans stuff up whenever it goes out of scope, not just when I remember to try/catch around its usage?

> Even from a pure security standpoint?

Yes. Memory problems indicate other errors in the program which can be fixed. An ideal program (which I admit is an extremely rare find) wouldn't care if it were on a GC or some RAII setup with respect to memory. However, the RAII setup allows me to ensure that my program cleans up after itself on the filesystem, over the network, or whatever other resource might be needing managed without issue; a GC setup leaves me back in the world of C's memory management assistance instead for such things. I know D's GC doesn't guarantee destructors are called (genius that, but probably something about undecidablility of the proper call order at program shutdown), but C# and Java don't even *have* destructors for such things.

Herman: Shipping Rust in Firefox

marcH — Tue, 19 Jul 2016 15:05:47 +0000

> on a pedestal

More like: in the foundation.

Memory is the lowest level, most basic resource. The lower level is a programming language, the closer it is to a memory management system. C is little more than a (manual and tedious) memory manager.

Also, isn't memory the only local resource that the language has exclusive control over? Except for memory mapped I/O which is rarely seen in user space.

> sometimes the resources you're managing aren't less important than memory,

Even from a pure security standpoint?

Herman: Shipping Rust in Firefox

mathstuf — Tue, 19 Jul 2016 12:46:26 +0000

So one thing I don't really understand is why memory is put on a pedestal in these languages. It's not the only resource that needs to be managed, so why doesn't the language help me with those resources at all?

Not that your point is invalid, but sometimes the resources you're managing aren't less important than memory, so proper RAII is more useful than a garbage collector.

Herman: Shipping Rust in Firefox

marcH — Tue, 19 Jul 2016 08:49:41 +0000

> I can only imagine that in C++ it's even worse :)

Despite[*] being much older, C and C++ got a proper [shared] memory model defined in their respective standards 7 years *after* Java did.

[*] or... because of it?!

Herman: Shipping Rust in Firefox

marcH — Tue, 19 Jul 2016 08:37:13 +0000

> I know of no other mainstream safe language. Java and C# avoid memory corruption but still allow plenty of ways to make simple errors

Sure, what difference can one or two orders of magnitude more bugs make as far as security is concerned? A system is just secure or it's not, right? Nothing in between...

Rust for safety

mathstuf — Tue, 19 Jul 2016 02:33:27 +0000

On the contrary. I've coded up hacks in Haskell by prototyping in Haskell's type system. If it compiles, I'm much more confident it will work than some open-coded hack. It can enforce that error codes are handled (or explicitly ignored). If my type signatures are correct, I know I am passing the right information without unnecessary leakage. A project which starts with this small boost is much easier to maintaining in the future should it persist past the hack stage (which many projects do).

Rust for safety

mathstuf — Tue, 19 Jul 2016 02:29:28 +0000

The compiler will assume you've enforced the rules of Rust though. No different than playing around in Python's C API.

Rust for safety

rahulsundaram — Mon, 18 Jul 2016 18:42:34 +0000

> That's to say, Rust's borrow-checking discipline fails to support random hacks.

Not sure what you mean? Random hacks can be unsafe

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

Rust for safety

ksandstr — Mon, 18 Jul 2016 15:12:16 +0000

>What makes Rust an easy choice is that, like C++, it imposes no overhead, and no runtime dependencies to complicate integration.

On the contrary, Rust imposes the worst kind of overhead possible: that on implementation. For programs written in C++ that're already down with the big-design-up-front philosophy this is insignificant, but unsurprisingly most software isn't written in Big Design C++.

That's to say, Rust's borrow-checking discipline fails to support random hacks. This is a major failure since most software arises from said hacks in one way or another.

abuse of DNSSEC signing keys

Cyberax — Sun, 17 Jul 2016 22:16:48 +0000

> afaict, this is not actually the case. I believe it's possible for a zone signing key to sign any RRSET within the zone at any level
Nope. DNSSEC keys are just that - keys. They don't use X.509 crap or anything complicated - the DNS standard directly defines the key encoding.

Signature validation is also straightforward - you get the parent's public key through NSKEY query and check your response. Then repeat it until you reach a locally available root of trust - it's completely hierarchical.

> If this were true, we would have already seen people doing this publicly. However, public efforts in this direction (usually called "DNSSEC transparency") are only in their infancy.
That's because nobody really cares, since DNSSEC is used only in a small number of domains. Even important domains like google.com are not signed.

abuse of DNSSEC signing keys

dkg — Sun, 17 Jul 2016 22:03:30 +0000

Cyberax said:

To intercept the connection, NSA/FBI/whatever would have to create a fake certificate and key for the first-level domain that you're using (for example, .io), sign it with the real root key, and then use this fake keypair to MITM the requests.

afaict, this is not actually the case. I believe it's possible for a zone signing key to sign any RRSET within the zone at any level, so there is no need to create a "fake" secondary key for the next-hop down the tree the root zone signing keys can just go ahead and sign the records for www.example.com directly. (i'm not saying that an attacker in control of the root signing keys would necessarily want to do this, just that i think it should technically be valid from the perspective of a DNSSEC validator.)

Cyberax also said:

This would be VERY visible, normally you would have only a handful of keys for each TLD. They can be easily pinned and checked.

If this were true, we would have already seen people doing this publicly. However, public efforts in this direction (usually called "DNSSEC transparency") are only in their infancy. I welcome that sort of auditing work, though! The potential rate of turnover in these zones is very high -- RRSIGs often have a short lifespan -- so verifiably logging all RRs signed by a given DNSKEY over time is actually a potentially resource-intensive task. It only gets more expensive if you want to log the signatures from DNSKEYs in the subzones, too.

Rust for safety

mathstuf — Sun, 17 Jul 2016 12:09:53 +0000

I think it's that the compiler phases don't pass all of the required information between them and fixing it is too invasive a change for the cases it fixes. If it were FOSS, there might be an enterprising contributor to tackle it, but I suspect there is higher ROI for things like getting the clang stuff released.

Rust for safety

micka — Sun, 17 Jul 2016 10:17:06 +0000

> not fixable due to it being a 35 year old codebase

So it's roughly the same age as gcc. It's a shame those two old compilers can't be fixed!

Herman: Shipping Rust in Firefox

JanC_ — Sat, 16 Jul 2016 20:00:17 +0000

They should have used small caps instead… :)

Rust for safety

pizza — Sat, 16 Jul 2016 16:37:51 +0000

> They also don't claim to be compliant.

Be that as it may, MSVC's "quirks" have historically made it quite challenging to maintain a cross-platform codebase.

Rust for safety

mathstuf — Sat, 16 Jul 2016 13:33:03 +0000

> a shockingly bad C++ "compiler" (MSVC)

While it has its quirks, it does catch warnings that are not caught by GCC or Clang. Most of its standards shortfalls are documented as such and are, generally, not fixable due to it being a 35 year old codebase (e.g., there are some edge cases where the parser just says "no" to valid constructs that will never be fixed due to the structure of the codebase; two-phase lookup (enable_if-area stuff) is also not implemented). There is now a Clang backend which has a cl-compatible command line interface which ships with the most recent versions of Visual Studio.

> severely lacking in standards compliance

They also don't claim to be compliant. For contrast, see Apple's Clang release where they *ripped out* TLS support (supposedly it is also a runtime failure; it compiles just fine). And they still claim to be compliant.

> A company with this track record should be nowhere near a ISO C++ standards process

Have you been to a ISO C++ meeting? No one company runs the show. Not by any stretch.

Rust for safety

marcH — Sat, 16 Jul 2016 06:42:15 +0000

> By following some easy rules, C++ coding can be about equally memory-safe, although it's hard to impose those rules on others' code. The place where C++ might never compete with Rust...

You meant: the other place whether C++ might never compete with Rust either...

Holy bubbles batman.

mathstuf — Fri, 15 Jul 2016 22:37:16 +0000

AFAIK, RequestPolicy is no longer maintained and the advanced setup for uBlock Origin is the preferred way. I also use Self-Destructing Cookies, but NoScript is replaced by uBlock Origin and uMatrix. Sure, noscript tags are broken, but it is one less extension to juggle too.

Herman: Shipping Rust in Firefox

tialaramex — Fri, 15 Jul 2016 20:43:56 +0000

Ah, very interesting. I was going on the Bugzilla ticket contents rather than the code, thanks for linking.

Holy bubbles batman.

drag — Fri, 15 Jul 2016 15:04:03 +0000

There is a limit to what Mozilla can do.

If you want to have a 'open web' then it's going to require new technologies (IPFS, etc) and the demand from web users to make it happen.

Herman: Shipping Rust in Firefox

drag — Fri, 15 Jul 2016 14:50:18 +0000

> In that case most people wouldn't notice if NSA/FBI/whatever did a MITM between them and their upstream (caching) DNS-server as long as the NSA/FBI/whatever also generated fake TLD-signnatures.

That is what the certificate pinning are TLD are for, as mentioned above.

When your localhost DNS connects to the network's DNS resolver it will obtain information for the TLD certificate. It will take note and remember the hash for that cert. If the cert changes later on for a MITM attack then the localhost DNS resolver will pick up on this and freak out.

Alternatively it wouldn't be too much of a burden for the distros to collect and ship TLD certificate information along with the localhost DNS resolver.

Cert pinning does work and it has caught MITM attacks against HTTPS when implemented in browsers.

The problem with this is that TLD certifications compromises would be a NIGTHMARE. Pinning can backfire because it can make it more difficult to deal with legit changes to certs.

Herman: Shipping Rust in Firefox

mjthayer — Fri, 15 Jul 2016 07:24:18 +0000

> There are some pretty awful problems with Convergence in practice and it is largely moribund.

For simplicity I will limit this to using certificates to establish web site identity. It seems to me that the first problem to be solved here is establishing that the site one is communicating with securely is really the one one expected (modulo typing mistakes in URLs, such as "www.mybank.com.badsite.net), and specifically not identifying the site's owners, nor the site's moral integrity. I would expect that this could be achieved using an off-line but regularly updated database mapping URLs to certificates which could be built up by automated crawling, probably using some ranking algorithm to keep the size down. This would be the white list.

The second would be a similar database of certificates known to be in use for bad purposes, the black list. Building this seems to me to be a similar problem to building a virus signature database, and presumably a similar level of quality would be to be expected. The black list would obviously take priority over the white list.

Would you expect the price tag of achieving this to be higher than that of similar databases which have been created?

Herman: Shipping Rust in Firefox

Wol — Thu, 14 Jul 2016 21:59:14 +0000

> True, but that implies that I'm paranoid enough to do that and keep updating the local copies when the TLD keys change (with appropriate verification).

But isn't that fairly easy? You pull down a set of "known good" TLD keys, and the system triggers an alert when they change, telling you to re-get the keys. Bit of a pain when they change unexpectedly, but the point is, not that it's secure or not, but that YOU ARE NOTIFIED when something changes.

Cheers,
Wol

Rust for safety

epa — Thu, 14 Jul 2016 20:23:31 +0000

On the contrary, someone who has spent the last twenty years collecting the various traps and gotchas in C++ is ideally placed to suggest ways they could be eliminated. This is also a reason why Rust, to an interested observer, looks like such a good thing: it is written by programmers who have experience using C++ in a large, mature codebase, and have been well exposed to its strengths and weaknesses. (The same is true of Mono, which was also originally a "there must be something better than C++" project following the experience of writing Gnumeric.)

I don't think the failings of Microsoft's C++ compiler are particularly relevant to Stroustrup and Sutter's safe-subset proposal.

Herman: Shipping Rust in Firefox

Cyberax — Thu, 14 Jul 2016 20:01:58 +0000

> True, but that implies that I'm paranoid enough to do that and keep updating the local copies when the TLD keys change (with appropriate verification).
It's not too terribly complicated to package such keys in Fedora/Debian/... or provide a public service accessible over the Internet/TOR/...

Herman: Shipping Rust in Firefox

farnz — Thu, 14 Jul 2016 19:52:11 +0000

But, if your operation is to remain stealthy, you need to sign every response I see for the duration of the appropriate TTLs; thus, instead of being only needing to MITM one Internet access session plus compromise one trusted CA (which is all you need in the current CA/B Forum PKI setup), you need to MITM every DNS query I send or receive for a week (that being the TTL of DS records in the root). If you don't, you run the risk that I'll see the "real" key, and discover that there's perfidy afoot.

Herman: Shipping Rust in Firefox

farnz — Thu, 14 Jul 2016 19:43:25 +0000

True, but that implies that I'm paranoid enough to do that and keep updating the local copies when the TLD keys change (with appropriate verification).

The thing about automatic caching is that it's transparent to me, and it's a useful performance optimization (so I'd expect OSes to do a degree of it behind my back). If the NSA doesn't take it into account, they risk being unmasked by their own bad opsec.

Herman: Shipping Rust in Firefox

raven667 — Thu, 14 Jul 2016 19:34:18 +0000

> These certificates won't be included in the operating system or browser's default trust stores unless the CA routinely issues proper certificates for the associated TLD

But of course they all do and would continue to do so, which is why the overall risk is unchanged.