Google says Android runs better when covered in Rust

Google has been integrating code written in the Rust programming language into its Android operating system since 2019 and its efforts have paid off in the form of fewer vulnerabilities. Memory safety bugs – like out of bounds read and write or use after free – account for more than 65 percent of vulnerabilities of high or …

[karlkarl]

Most of our Android bugs came from binding between the Java and the C, C++. This was error prone and had a lot of boilerplate.

Rust won't really fair any better in this case. Bindings are nasty business and marshalling data can't offer any guarantees.

(Admittedly, NativeActivity and homogenous C++ made life much better)

[Mostly Irrelevant]

I believe they're talking about in the kernel and system services, not running on top of the Android runtime. The core services in Android are all native code.

[fg_swe]

Good To Hear !

After working since 2006 to promote Memory Safe Languages as the last and most mighty line of defence against cybernetic threats, I applaud Google's efforts to use Rust in Android.

The idea of memory safety is not exactly new, the Algol Mainframes did have some memory safety features in the 1970s. It was AT&T, who considered it a luxury and promoted Unix and C instead. One hit into the Linux or Windows MegaKernels, and the ship is sunk.

If Microkernels are like frigates with 10 or more compartments, memory safe operating systems are comparable to ships build from metallic foam. Such a ship can take many hits without going under.

[Anonymous Coward]

Re: Good To Hear !

The idea of memory safety is not exactly new, the Algol Mainframes did have some memory safety features in the 1970s.

The only version of Algol which had heap allocation was Algol 68, which was a failure. Earlier versions of Algol only had stack allocation. Any language without heap allocation is wonderfully memory safe but also as limiting as something like a scientific calculator.

So you can knock C all you like because it's not as memory safe as Algol 60 or as a scientific calculator (remember, we're ignoring Algol 68 which was an evolutionary dead end), but C was necessary and needed because it offered power, portability, and flexibility which other contemporary languages did not.

So your choices were 1) Algol 60 with non-portable assembly for any degree of power, 2) Algol 68, a dead-end, or 3) eventually C or Pascal. Unsurprisingly C and Pascal went through into the next round.

[fg_swe]

Algol Mainframes ?

If that would be true, how could the Algol Mainframes of ICL, Burroughs and IPMCE be useful computers at all ?

How did they manage without heap memory ?

I must concede I do not have first-hand knowledge of Algol, but from what I can read they did have several memory safety features such as index checking and hardware memory typing.

[fg_swe]

Re: Algol Mainframes ?

Also See

https://retrocomputing.stackexchange.com/questions/7953/first-language-with-c-like-memory-management

https://news.ycombinator.com/item?id=5349354

https://rosettacode.org/wiki/Memory_allocation#ALGOL_68

https://twitter.com/enf/status/1049453387492679682

https://www.dcs.gla.ac.uk/~wpc/hi/heaps.pdf

It looks like the Algol standard never specified how to collect garbage, though.

A comment from an Algol mainframe programmer would definitely be useful in this discussion.

[Anonymous Coward]

Re: Algol Mainframes ?

How can we take your comments on memory management seriously if your proposal is a language which does not have a heap or a language which cannot free allocated memory and may not even have garbage collection until the program exits?

[fg_swe]

Algol "heap" keyword

Look it up. It is comparable to Java's new. Implementations would use a mark+sweep collector to reclaim the memory after use.

[Anonymous Coward]

Re: Algol "heap" keyword

You have given me a bunch of links which say you allocate heap memory in Algol 68. I didn't claim otherwise.

I said you cannot free heap memory in Algol 68 and you have not posted one link which shows freeing memory in Algol 68, because you can't. The only way memory can be freed in Algol 68 is if the program exits or if the implementation does garbage collection, but there are no specifications as to how this is done and many implementations of Algol 68 don't do it.

C and Pascal fixed this oversight in Algol 68 by allowing the programmer to free heap memory.

I understand you have a lot invested in Algol 68 and earlier versions of Algol because you've spent months singing its praises about memory safety, but I'm afraid the emperor has no clothes.

[fg_swe]

Really ?

Please have a look at the Algol mainframes. They definitely have very interesting memory safety features.

https://www.theregister.com/2020/05/15/algol_60_at_60/

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

[fg_swe]

Burroughs Algol Mainframes

https://www.digm.com/UNITE/2019/2019-Origins-Burroughs-Algol.pdf

Definitely a much better concept than C+Unix and the IBM/360 world of untyped memory. But alas, cheaper often wins over better. At least initially.

[fg_swe]

From the Trenches

https://groups.google.com/g/comp.sys.unisys/c/5apvpaA2fZs

[dajames]

Re: Good To Hear !

The only version of Algol which had heap allocation was Algol 68, which was a failure.

Algol68 was not a failure. It was a language so far ahead of its time that it was widely misunderstood and unjustly condemned as being "too complex". It was, however, a highly effective, efficient, and readable language that was used for production code all over the world for some years.

It was a language that was widely reviled by some vendors (IBM, in particular) as competition for their own compilation tools (PL/1 in particular).

It was a language that has been a major influence in just about every language developed since, from C++ to the bash shell.

I wouldn't suggest trying to use a 50-year old language for anything today, but don't write it off as a failure, and do understand that if it was a dead end that was because it was sidelined by commercial interests in other toolchains.

Modesty forbids me to suggest that readers might find it interesting to read a short retrospective on the language that I wrote, to celebrate its 50th anniversary, in Overload, a journal of the ACCU.

[fg_swe]

"50 Year Old"

We Swabians have a 50 year old aircraft in the museum, which is still better than anything else in this class:

https://www.youtube.com/watch?v=x3YueCf1JeI

Higher payload, higher speed, better range than the V22. Killed no-one, while the V22 killed more than 40 airmen(not due to enemy fire !).

[werdsmith]

Re: "50 Year Old"

But 10 engines? Clever technology demonstrator but needed to be developed to be a practical in service machine.

[fg_swe]

Dornier 31

I never said it was cheap. But it still has the best performance of all planes in its class. And also the best safety record. Only slavery is cheap.

[Anonymous Coward]

Re: Good To Hear !

I'm not doubting it's well designed but it still was a commercial failure, some of the reasons why it did not do well in the marketplace are here.

On the subject of memory management, only Algol 68 had a heap and even then it only had a command to allocate memory, not to free it. Garbage collection if it existed was left as an exercise for the implemention.

If I write C or Pascal programs like that I avoid all use-after-free vulnerabilities as well. Therefore our friend who uses every C/C++ or Rust story to wax lyrical about Algol is spouting nonsense.

[fg_swe]

Unisys MCP Algol Heap Memory

From

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

"Also, low-level memory allocation system calls such as the malloc class of calls of C and Unix are not needed – arrays are automatically allocated as used. This saves the programmer the great burden of filling programs with the error-prone activity of memory management, which is crucial in mainframe applications."

They do not need "new" or "malloc", as the CPU+OS will handle dynamic memory allocation and freeing !

In other words, the whole idea of explicit memory allocation is not the only viable one.

[Anonymous Coward]

Re: Unisys MCP Algol Heap Memory

Once again for the hard of understanding, there is no freeing from the heap unless the Algol 68 implementation implements garbage collection, which was unspecified in the Algol 68 standard.

5.2.3. Generators

{The elaboration of a generator, e.g., LOC REAL in xx := LOC REAL := 3.14, or of a sample-generator, e.g., [1 : n] CHAR in [1: n] CHAR u, v;, involves the creation of a name, i.e., the reservation of storage.

The use of a local-generator implies (with most implementations) the reservation of storage on a run-time stack, whereas heap-generators imply the reservation of storage in another region, termed the "heap", in which garbage-collection techniques may be used for storage retrieval. Since this is less efficient, local-generators are preferable; this is why only LOC may be omitted from sample-generators of variable-declarations.}

No amount of running on a Burroughs machine will change that.

[fg_swe]

Re: Unisys MCP Algol Heap Memory

Unisys implemented lots of software in Algol, including compilers. I fail to see how they could have done that without heap memory.

And I can imagine that they built heap memory management into the OS. Essentially you declare a pointer, dereference it and MCP will allocate the object/array "on the fly". MCP experts please correct me if I am wrong.

They can then run mark+sweep in the MCP system, just like the JVM does.

https://www.informit.com/articles/article.aspx?p=1671636&seqNum=3

Unisys is not bound to limit themselves to the official Algol standard.

[Anonymous Coward]

Re: Unisys MCP Algol Heap Memory

What are you not understanding?

- Algol < 68 has no heap.

- Algol 68 has a heap.

- Algol 68 can allocate from the heap.

- Algol 68 cannot free from the heap while the program is running unless the Algol 68 implementation has chosen to implement garbage collection.

Anything different from that is non-portable Algol which might work wonderfully on one particular mainframe but nowhere else.

And I can imagine that they built heap memory management into the OS.

Every damn OS under the sun cleans up a process' stack and heap when the process exits.

[dajames]

Re: Unisys MCP Algol Heap Memory

Once again for the hard of understanding, there is no freeing from the heap unless the Algol 68 implementation implements garbage collection, which was unspecified in the Algol 68 standard.

Do you know of any real-world Algol68 implementation that did not implement a garbage collector?

Asking out of interest, because I've used several, and they all did.

[martinusher]

Re: Good To Hear !

If you're in the business of making phone switches (exchanges) like Bell Labs/AT&T then you're also likely to be designing and testing your products thoroughly before releasing them. 'C' was never intended for the 'pile it high and get it out as quickly as possible' school of programming, that's what "high level languages" are for -- they protect the system from the programmer.

Its the same with those organizations who couldn't use segmented -- protected -- memory properly. Nobody forced them to put everything in one huge memory puddle just hoping that one application wouldn't interfere with another. It was just easier / quicker / cheaper to do it (and you can always turn the system off and on again if things go pear shaped).

(Someone else described Algol 68 as a "failure". Its problem is that it tried to cram too many features into it (C++ please note), the biggie being able to declare procedures inside procedures. Essentially unimplementable with the technology of the year (and not a good idea in the first place, IMHO). The thinned down 68R version worked fine, its arguably the best language I've ever had the pleasure of using. Again, though, it doesn't appeal to the 'pile high and get it out fast' programming school.)

[david 12]

Re: Good To Hear !

The documented history of c is that it just grew, and that mostly because it was associated with unix -- a programming language and OS pair that was popular in ATT because it was available and easier than developing a new language and OS for each new processor.

That is, pile it high and get it out quick.

[fg_swe]

Real World

In the real world, engineering managers are in most cases not the best+brightest engineers. Rather, they know how to "herd cats". Social skills.

If "all other engineering managers" use C, they will do that too. Regardless of the consequences.

In other words, improvements of software security and safety will come from engineers+scientists, not managers.

Modern day telephone software apparently is quick+dirty stuff, which is why the phone network now has one-day-crashes per three years or so. A long time ago, they aimed for "5 minutes in 30 years". The days of ISDN.

https://www.softwaretestingnews.co.uk/21345-2-gchq-director-huaweis-engineering-very-shoddy/

[Anonymous Coward]

Re: Real World

I cannot find where it says the Huawei's shoddy engineering is down to "engineering managers using C" in your cited article. You're really clutching at straws here.

[fg_swe]

Re: Real World

The quick+dirty Huawei stuff is especially dangerous, because it is coded in C and C++.

I was responding to your claim that telephone software would be somehow more robust. Maybe that was a feature of the past.

[Anonymous Coward]

Re: Real World

What? It wasn't my claim either.

[Kevin McMurtrie]

Googley

Google is stuck with minimal C++ type safety because they use a nonstandard language subset with cascading feature breakage.

https://google.github.io/styleguide/cppguide.html

It's enough of a disaster to make employees use Google's nonstandard version of Golang.

[DrXym]

Re: Googley

Erm... Google have a C++ style guide because C++ is a vast, broken language with numerous pitfalls and corner cases and their guide is a mitigation against the worst excesses a programmer can indulge in. Just read it if in any doubt since they explain and justify every rule.

And what's this "nonstandard subset" about? There are plenty of "standard subset[s]" all of which contradict each other or have a different emphasis - MISRA, CERT C++, HIC++ etc. Or perhaps you don't like subsets at all - whatever the C++ standards say goes and the abuses they allow. But that is the whole problem.

So basically, a) you have no guidelines and everything blows up, b) you constrain yourself in some fashion incurring "cascading feature breakage" as you put it and possibly dropping tens of thousands on static analysis tools just to know if you're approaching safety, or c) you use a safe language and get safety out of the box.

Is it any wonder Rust is being used and so successfully?

[Dan 55]

Re: Googley

It seems Google's style guide prohibits RAII... what do they honestly expect will happen when it's the major C++ design pattern used for memory safety?

They might as well mandate that every file in Rust be braced in unsafe { } and then complain about the results.

[DrXym]

Re: Googley

The answer is it doesn't prohibit RAII. It might have in the past for reasons but it doesn't now. But since you mention RAII, that is a minefield in C++ so I could see why guidelines might require any such class to be non copyable or to correctly implement the rule of 3 or 5. RAII is also something which is safer in Rust because it moves on assignment by default.

[Dan 55]

Re: Googley

It also prohibits exceptions, so a constructor would fail, clean up after itself with RAII, and throw an exception to the caller which also unwinds the stack, you now have to communicate that object creation somehow failed, put the object into a failed state which does nothing, perhaps clean up with the limited RAII that is allowed (I still can't see how the GSC's destructor rules allow proper RAII), and hope that the caller tests and realises that.

So problems can occur simply because Google's style guide bans best practice.

There doesn't appear to be a Google Rust style guide which actively works against Rust design patterns which are accepted as best practice.

[DrXym]

Re: Googley

You say "also" but it *doesn't* prohibit RAII. The only reference to "RAII" occurs exactly once in the section on exceptions which is probably why you go to talk about that.

Second, the issues with exceptions in code are well described and Google choose not to use them because they can break code that doesn't expect them. They are also vulnerable to wild abuse. Their reasons are spelled out.

And it's very easy to avoid using them too even for RAII.

It's probably also why most modern languages like Swift, Go, Rust don't use them either, choosing to make error part of the function signature. Swift uses a pseudo throw try catch but it's basically syntactic sugar to call a function that returns a result or an error. Go allows a function to return a value or an err. And Rust has an explicit Result<value, error>.

[Dan 55]

Re: Googley

I looked for "constructor", "destructor", and "initialize" and found a long list of caveats which could prevent RAII being used in many cases.

I'm also surprised that RAII is not mentioned in Google's style guide apart from in passing when saying that exceptions shouldn't be used. Exceptions and RAII used together are a valid way of avoiding memory vulnerabilities in C++.

Also Google mentioned that they decided not to allow exceptions because their existing code did not deal with exceptions. If they are banning one C++ feature and not encouraging another to avoid changing legacy C code and those two features avoid memory vulnerabilities, you simply cannot conclude that the problem is down to C++ and it must be thrown out and replaced with Rust. They never threw out C and replaced it with C++ in the first place.

The right way to do it was updating the C code instead of not using C++ features because they didn't work with existing C software and they paid the price for not doing that. Now they've decided to throw out C++ but they still haven't worked out that they're doing that precisely because of their coding guide.

[DrXym]

Re: Googley

A lot of heavy lifting going on here. The fact of the matter is the guidelines don't ban RAII objects. Click the link and searching on RAII and it becomes immediately clear. Maybe older versions of the guidelines did in the past (someone would have to point a link to say) but they absolutely don't now.

And the absence of exceptions in C++ doesn't preclude using RAII either. There are a bunch of ways it could be done. Using a static helper that returns an optional with the RAII object would be one way. Or adding an is_valid() to the object so it can be tested for validity. Or using a builder pattern. If your code wants move on assign semantics you'd have to have a nillable state anyway.

If this weren't obvious I'd point out that Rust easily supports RAII but doesn't rely on constructors, destructors, exceptions or suchlike either. How is that?

[T. F. M. Reader]

Re: Googley

I don't quite see where the style document prohibits RAII, but I only gave it a quick look. Mentioning RAII is very much on topic though.

In my rather long career of writing C and C++ code I never found safe usage of memory difficult. All you need is a bit of discipline. In C++ RAII is an important technique to promote such discipline. C/C++ don't prevent you from being careless, but this does not mean you should be. It's not difficult to be careful at all, though it does require a bit of effort to think of ownership and the full lifecycle of your objects. That, incidentally, is crucial for lots of other reasons beside memory safety.

All the talk of the advantages of "memory-safe languages" is basically "elf'n'safety" cushioning, a.k.a. not trusting engineers to be adults. There may be reasons for that (and yes, I've seen rather spectacular examples), but it does not address the root cause. I have no hard data, but I strongly suspect that many people who blame C++ for the fact that they never bothered to learn to use it effectively won't be effective, and will write dangerous code, in other languages as well. On occasion they will write so much code to work around language restrictions to do something fairly simple that the result will be dangerous just because of that. Some other people can use C++ effectively themselves, but blame it for their lack of trust in others whom they refuse to treat as adults who can be educated.

Some parts of Google's style guide certainly smell like not trusting programmers. While I didn't find a prohibition on RAII, the prohibition on forward declarations is a case in point. I would rather encourage Google programmers to use forward declarations as much as possible, to loosen compile time dependencies. I imagine Google may have a few large projects where this will be particularly important. The main justification of the prohibition is based on a contrived example involving ambiguous code. Well, C++ allows you to write ambiguous code almost as a matter of philosophy, but it doesn't mean you should. I looked for a "don't write ambiguous code" style guideline, but didn't find it. The last argument in that section looks downright weird as well. If Google engineers write code like that they should think of ways to address the real issue rather than blame the tools.

Disclaimer: the above must not be construed as implied criticism of Rust.

[fg_swe]

FALSE

You bring up the "good software engineers don't produce memory errors" argument once more. In reality, even the most seasoned engineers then and now have Covid 3333(a.k.a. "flu"), a fight with their wife, trouble with a teenage kid or the like. Bang, memory error.

It has happened in ALL major systems from HP/UX kernel to VxWorks TCP/IP stack. In between, WNT, Linux kernel, Unix user land, Solaris make, g++, YOU NAME IT.

[fg_swe]

Automotive MISRA Experience

I was part of auto software engineering projects up to ASIL-D. I say this:

1.) MISRA C subset is definitely useful and makes sense for other domains, including datacenter, phone, PC.

2.) MISRA C will do little to prevent integer under/overflows or index errors. Static checkers (PC Lint, PolySpace) do help here. They are now mandated in most projects. Static checkers have limited power, though. Sometimes runtime checks are required to be memory safe. C cannot do that. MISRA or not. SPARK Ada, Rust, Sappeur, do dynamic index checks.

3.) Using C in safety-critical domains (auto, rail, aerospace, medical) is a second-rate decision. SPARK Ada is still superior in many ways. Engineers who can write C can be made to write Ada, but C can never be made as safe as Ada, even with static checkers tacked on.

[Code For Broke]

Is it just me, or are you also mumbling to yourself, "correlation is not causation"?

[bazza]

Not me!

But to address the possibility that this is simply coincidence, it's worth noting the sharp drop in memory related vulnerabilities, 76% in 2019 down to 35% in 2022 (and there is still C++ being used), a decline of 41%. The numbers themselves (223 to 85) are also quite large; one does not need the sharpest of actuarial minds to see the unlikliness of a coincidence.

If it were random coincidence, it would unprecedented in computer science history, and one would expect those figures would reverse at some point.

[Richard 12]

Or simple decline

Is it not more plausible that the decline is simply that there are fewer issues left to find?

Most code is written at the beginning, after all.

[mmstick]

Re: Or simple decline

There's at least 30 years of research to prove that this is not the case. Some of the novel concepts that give Rust the ability to eliminate these kinds of vulnerabilities was already pioneered and proven in research papers that were published when I was born in the early 90s.

[fg_swe]

Singularity OS

Microsoft already had it running in the labs, but decided not to offer it as a product. It could have threatened their millions-of-lines-of-C++-code hairball WNT.

https://www.microsoft.com/en-us/research/project/singularity/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fprojects%2Fsingularity

[Anonymous Coward]

Re: Singularity OS

Windows NT is written in Assembler and C, only the graphics subsystem is written in C++.

[fg_swe]

Re: Singularity OS

All of the WNT kernel had serious memory error exploits, including the TruType font subsystem they dragged into the kernel. Visit a "bad" website with poisoned fonts, have a kernel exploit !

[Anonymous Coward]

You too can write programs in Crayon

in a nice safe padded cell, wearing a sleeveless jacket.

[mmstick]

Re: You too can write programs in Crayon

Is the memory safe C/C++ code and the programmers who write it in the room with us now?

[Anonymous Coward]

Re: You too can write programs in Crayon

I must be free to write shitty, leaky code!!

[cardich]

Lying Cheating

Rust is the biggest lying cheating in the history of computer science.

[Code For Broke]

Re: Lying Cheating

Any evidence to back up those claims?

[fg_swe]

Re: Lying Cheating

I assume this is good old F.U.D. propaganda, completely devoid of substance.

[werdsmith]

Re: Lying Cheating

There are many people who have invested years in their career with traditional languages, they really don’t want to deal with anything new and are now looking over their shoulders a bit worried that something is going to sneak up and eat their lunch.

[Spazturtle]

Re: Lying Cheating

Only the bad programmers are worried, the good C programmers will be able to spend the last 20 years of their career getting paid a lot of money to maintain legacy systems.

[mmstick]

Re: Lying Cheating

The good C programmers already made the transition to Rust years ago, and have been driving force behind the Rust adoption. It's not junior programmers that are making management decisions, after all. Maintaining a legacy codebase that few people use anymore is soul-sucking work, where the money isn't worth the toll that it takes on your life.

[bazza]

C++ Memory Safety?

Well, it may indeed be possible to write memory safe C++ and use static analysis to show that safety has been accomplished, but it's a poor way of doing so. Firstly, from a reviewer's point of view, they have to be able to set up, run and understand the output of the static analysis tool that is used. Secondly, that does not descend down into any of the libraries (written in C, C++) that the code may have chosen to use. Thirdly, static analysis is a process prone to raising "consessions", places where there has to be some dialogue between dev and review to say why this static analysis whinge can be ignored. There's nothing formal in the syntax to say "here we are unsafe", there has to be something separate from the code to highlight it and explain it.

With Rust, so far as I understand, it's simply a matter of 1) does the "unsafe" keyword appear anywhere in this code, and 2) does it compile? And I suppose a final one of does it use only Rust-written libraries? If the answers are no, yes and yes, you're good (assuming the compiler is correct). If the first answer is "yes", you know exactly where to look with a very beady eye.

The point is that, to make C++ memory safe there's an awful lot of holes to plug, including in places you can't get to. With Rust, there's just one easily found hole that would have to have been drilled on purpose by the developer.

On these stats reported in the article, well I suppose that it just goes to show that if you use a more rigourous language, you'll get a better result.

[Dan 55]

Re: C++ Memory Safety?

Thirdly, static analysis is a process prone to raising "consessions", places where there has to be some dialogue between dev and review to say why this static analysis whinge can be ignored. There's nothing formal in the syntax to say "here we are unsafe",

If we're talking compiler checks:

#pragma warning disable/restore

#pragma message

Otherwise the static analysis tool will allow you to disable particular static analysis whinges.

The point is that, to make C++ memory safe there's an awful lot of holes to plug, including in places you can't get to.

Follow modern design patterns and use compiler checks and static analysis tools to enforce them. No, you can't "get to" libraries without source code but you can't in Rust anyway. If you can "get to" libraries with source code then you can run static analysis on the library too and fix flags which are raised, which is more practical then rewriting whole libraries in Rust and causing a whole new set of bugs.

[bazza]

Re: C++ Memory Safety?

Whilst it's true that one cannot "get to" a Rust library's source code, provided that that source code didn't contain "unsafe" anywhere then you have the compiler's guarantee that, whatever else the library developer did, they didn't get memory usage wrong. For userspace libraries, it's unlikely that unsafe was required in the writing of the library.

It's this "safe by default" thing that C++ cannot match.

It'd be quite nice if Rust object code had flags indicating whether or not "unsafe" had been used, to allow onward users of it to know.

[chololennon]

Re: C++ Memory Safety?

"It'd be quite nice if Rust object code had flags indicating whether or not "unsafe" had been used, to allow onward users of it to know."

That could be a good idea to be added to this:

https://github.com/rust-secure-code/cargo-auditable

[fg_swe]

Static C++ Checkers

Are you sure these static checkers are as complete as the Rust or the Sappeur compiler ? For example, will they detect unsafe multithreading under all conditions ?

Most of these checkers are heuristic tools with lots of value, but definitely not as complete and strict as the compiler of a memory safe language.

Mr Stroustrup makes similar claims, but I still miss a description of how he intends to achieve similar safety with a C++ compiler and some static checker bandaids.

[Anonymous Coward]

Re: Static C++ Checkers

"Are you sure these static checkers are as complete as the Rust or the Sappeur compiler ?"

OMG!, you again advertising your compiler. The article is about Rust/C/C++.

[fg_swe]

Re: Static C++ Checkers

There are very few languages which model multithreading in the type system. Sappeur is one of the first to do so.

[Anonymous Coward]

Re: Static C++ Checkers

Given your claims about Algol 68's memory management, a period of quiet reflection might be in order.

[DrXym]

Re: C++ Memory Safety?

That's exactly it. Safe by default. If your program crashes, i.e. unexpectedly dies rather than panic and yielding a stack trace, then the first thing you do is go looking for the word "unsafe" in your code or anything it depends on. Guaranteed the crash is in one of those and it represents a tiny fraction of your codebase.

I have a project which is hundreds of thousands of lines of code which I've been working on for 5 years. In total I have 3 unsafe blocks, all calling OpenSSL (to use an esoteric padding / signing functions). It has crashed ONCE in all that time and it was in one of those blocks where I was passing the wrong arg in a C call.

It's also the case that the word "unsafe" is anathema for Rust. You use it when you *must* but not otherwise. Big unsafe fixing splurges have happened in projects like Actix Web where it was deemed there were too many of them.

[fg_swe]

Memory Safety and Crashing

Note that a deterministic crash, which stops the program and yields a debuggable core file is much more useful than the "undefined behavior" stuff you can get from the equivalent C++ program:

A) silent compromise by a cybernetic attacker. Reconnaissance of secret data, commandeering of the program and the attached system.

B) a "mysterious" crash much later, in a totally unrelated code module, because a bug in module A affected the memory of module F.

C) "mysterious" crashes in dozens of unrelated pieces of code due to one multithreading error destroying the heap basically at random

Memory Safety is NOT about perfection, but about Containing Bugs Where They Occur.

[mmstick]

Re: C++ Memory Safety?

I'd mention that even if you are using the unsafe keyboard, you still have to adhere to the borrow checker and other compiler rules within an unsafe scope, such as the ownership model, aliasing XOR mutability, and type marker constraints. And it's by far much easier to perform a code review or an audit when the bits of unsafe are clearly labeled as such.

Also, there's a lot of great constructs within the Rust core library that make it trivial to handle raw pointers safely. There are zero-sized types that you can wrap pointers in which make interactions with them safer. Such as allowing the compiler to track ownership, leveraging it to prevent aliasing, giving it the ability to check your type transmutations, and more.

It also helps that the language syntax naturally encourages you to write code safely, so it's not a matter of "bad" programmers versus "good" programmers. It takes a lot of extra syntax to interact with code unsafely, as opposed to C or C++ where it takes a lot of extra effort to write code safely.

[fg_swe]

Unsafe Sections

Obviously, unsafe code sections should be

A) Minimized

B) Ideally only in low-level libraries (e.g. file access, sockets, specialized I/O such as reading an A/D converter)

C) Thoroughly reviewed by senior engineers

Engineering is never about 100% risk avoidance, but about minimizing and controlling risk. Those who want religious perfection should go into a monastery and better shut up for the rest of their (sorry) life.

[sgp]

Automation has made flying a lot safer. Memory safe languages can make programming a lot safer. But just like flying, you still need to know what you're doing.

[fg_swe]

ABS Brake

"ABS Brakes make driving much more safe, but you can still kill yourself by reckless driving"

[Eric Olson]

Re: ABS Brake

Every winter, I'm reminded that ABS brakes are a feature I would never want to live without again.

[captain veg]

Re: ABS Brake

I guess you never learned to cadence-brake.

-A.

[fg_swe]

Yeah

When you don't write totally memory-error free C++ code, you do Perfect Braking, correct ?

Also when two wheels are on ice and the other two on concrete, you operate each wheel's brake independently using four finger switches ?

[captain veg]

Re: Yeah

I ride a motorcycle. Two wheels, two brakes, two levers.

-A.

[Adam Inistrator]

I would wager that most of the drop in defects will be due to a drop in defects in C++ code over the past 10+ years as modern C++ has been implemented ... and nothing whatsoever to do with the absolutely *tiny* fraction of Android coded in Rust.

The arguments correlating the drop to Rust being very weak, you have to wonder about the motivation of those who dare put such a non sequitur argument forward.

Why no breakdown of the drop in defects by language?

[DrXym]

Here is the link to the blog post:

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

Quite clearly they are still writing new C and C++ code, far more than there is new Rust code. We can assume that this accounts for much of the new bugs, not the existing mature code. But so far zero memory vulnerabilities found in the new Rust code.

The inference to draw is that it is working as designed, reducing memory issues. Rust isn't going to fix application logic errors (e.g. forgetting to check X is true before doing Y) but that wasn't the reason for using it. It was to reduce the kind of errors that have plagued C/C++ programming since forever - over/underflows, null pointers, double frees, data races etc.

[Anonymous Coward]

I found the numbers a bit questionable:

"From 2019 to 2022 the annual number of memory safety vulnerabilities dropped from 223 down to 85,"

and

"In Android 13, roughly 21 percent of new native code is written in Rust."

So by using 1/5th of "safe" code it results in a 3x drop in bug rate?

[Adam Inistrator]

Simple minded people conclude what they want from weak data. No conclusion can be drawn from the data as presented. Apart from the failure to publish the actual NUMBERS of defects and instead relying on the ever misinterpreted percentages, just one gaping hole in the logic is the assumption that the C++ and Rust code is doing equivalent work.

[mmstick]

The numbers and metrics that you're asking for is in the text if you take the time to read it. It's quite plain to see for anyone that's not biased against Rust adoption.

"Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production."

They've added Rust code to the Android 11, 12, and 13 releases. In total, there is 1.5 million lines of Rust code in Android 13. To date, across these releases, zero vulnerabilities have been found in the Rust code. By this logic, there should have been 15,000 vulnerabilities within the Rust code. And yet here we are with zero. To disagree with this conclusion is merely denial on your part.

[mmstick]

If you spend the time to read the blog post then they did clearly label that 21% of all new code was written in Rust, and the other 79% of newly-written code is in C and C++. And within that new code, there's been zero vulnerabilities across the last three Android releases whereas 1 out of every 1000 lines of C/C++ had a vulnerability. So yes there's a strong correlation between vulnerabilities in C/C++ compared to Rust. Google isn't alone in releasing articles and papers like this. There's already been a myriad of research papers and blog articles from academia to Microsoft/Google.

[fg_swe]

But

Both have very similar memory safety issues:

A) unchecked array access

B) funny raw pointer stuff

B2) super funny pointer casting (e.g. int to pointer)

C) lots of problems from a lack of proper multithreading safety model in the type system

[captain veg]

Re: But

A) Yes. Would you prefer a performance hit even when no error is possible?

B) I'm sorry that you don't understand pointers.

B2) You can do that if you want. No one ever does.

C) I dare say that you are right. There's certainly no mention of threads in K&R and I try to avoid them.

-A.

[fg_swe]

Re: But

A) In many cases (e.g. for loops), the index checking of a Rust, Java or Sappeur program could be turned into an O(1) operation.

B) I was referring to: obtaining a pointer into the middle of an array, then incrementing or decrementing w/o any sanity check of the runtime system or the compiler.

B2) I have seen plenty of that cr4p, because some people did not know STL and abused an MFC integer array to store pointers. Oh yeah, and void* pointers and lots of other obscenities.

C) Multicore CPUs are now standard, even in laptops of the $1000 range. In the datacenter, we have multithreading since 1998 or so. Even the world of auto now uses multicore MCUs for demanding things like video processing.

[sabroni]

Re: I'm sorry that you don't understand pointers.

Ah, one of the excellent C++ coders who doesn't fuck up, like all of them posting on here. Maybe if you lot weren't on here explaining how C++ memory leaks aren't a problem and were instead writing super safe C++ code we wouldn't be in this situation.

Every article that mentions Rust has a comment section full of C++ devs who refuse to own the shit show that they've created.

[fg_swe]

Re: I'm sorry that you don't understand pointers.

Issue C is still as bad in C++ as in C.

[Anonymous Coward]

That google guy, he's never shipped product..a "researcher".

A quick look at his resume and its just a whole bunch of "research" positions. Not the slightest evidence he has ever shipped actual real life product code. You know, software that people use. Because if he had he would have known that we those of us who do ship system / application code written in C/C++ (and asm) have been using for more than 30 years a whole bunch of tools that do a great job of quickly tracking down all the problems that the YAFL Rust is supposed to fix. Long before DTrace we have tools like SoftICE (back in the 1980's) that could track memory leaks and related unsafe memory usage. Etc.etc. Many many tool.

So yet again its just more Rust spiel written by people who haven't a clue about how software has been developed, validated and shipped in "unsafe" languages like C for the last five decades. Hell, there have even been TXL grammars and scripts for the last 20 years that will do at least 99.99% of job of source code verification for safe memory usages in C and C++. And to sneak through the last 0.01% you have to work very hard at using language tricks.

So just more Rust bollocks from academic kiddie types who cannot be arsed to find out how commercial code has been developed and shipped for many decades. But rather spend time playing with yet another new toy language. Only one high profile end user application has been written in Rust and the result has been catastrophic. Whats Firefoxes market share now? 2%? And almost unusable due to technically incompetent levels of memory resource usage. And this is not the first time a successful product has been destroyed by - Lets rewrite in a completely new language that almost no one uses - either. Thats been going on for many decades too. A rewrite in Modula 2 killed Wordstar back in the 1980's to pick just one example

[fg_swe]

Male Cow Stuff

You claim that seasoned software engineers using C++ never had trouble with memory errors. Which could only mean that rookies worked on WNT, Linux Kernel, Unix kernels, Solaris make, Unix Userland tools, yacc and lots of other widely used programs. Because ALL of them had serious memory errors, which were often discovered decades after their creation.

Remember the HP/UX Ping of Death ?

Remember the exploitable memory errors in the TCP/IP stack of VxWorks ?

Remember how lots of memory errors were found in "well aged" Unix user land tools the first time they were executed under valgrind ?

Then you claim that "SoftICE" would be of help to detect memory errors. I cannot see how.

Conclusion: you have a nice life off C and C++ development and you don't want to learn anything new. So you blasted out some lies and half-truths.

[Anonymous Coward]

Re: Male Cow Stuff....another clueless code kiddie?

So sloppy lazy programmers write crap code. Big deal. So tell me something thing new. Lazy sloppy programmers write buggy code in EVERY language. I've seen lazy buggy code written in everything from FORTRAN and Algol to Kotlin and Swift and everything in between. In more than two dozen languages by this stage in.

If you have actually worked on (or run) many COMMERCIAL SOFTWARE dev teams over the decades (and had to clean up the messes left by others) you would know that there are large numbers of programmers on dev teams who cant be arsed to actually do the most basic research on what tools are out there. Or use the ones that are provided. Even basic tools can find most common mistakes. Or often just turning on the compiler warnings. Cleaning up the mess is usually just turn on all the compiler / linker warnings and run the code through some very basic tools. If that does not solve the big problems then thats Throw Away and Start Again code. A waste of further dev time.

I did notice that all your examples seem to be from the Unix world. One way or another. I wont go into the reason why that does not surprise me. Lets just say thinking of end users of software has never been top of the list for Unix programmer in my experience for as long as I've used it. Since the early 1980's. Or even the most basic handling (or even returning) of the simplest error codes. You should code review some of the source code. Most of it fails robust error handling. Although OpenSolaris / OpenIndiana is a joy to read.

SoftICE. Yeah the software only version involved some juggling but did what I needed and was more reliable than the software only tools at the time which did not do device driver level ops. But the hardware card version was almost as good as a JTAG debugger on a PPC. It was easier on the Mac. You just patched out some ATRAPs. So when DTrace came along knew exactly how to use it to find in a few days all the memory leaks / compromises in a huge codebase that had been shipping for several years.

So it sounds like I have been shipping code since before you were born. And I might add have a far wider of production use of languages of all types than you ever will. Currently in the process of creating a Domain Specific Language for an end user application. Not end user script. ANTLR could be used to churn it out but given its use profile TCL_Interp looks like the way to go. Timewise. Rather spend time added some functional language primitives. Just like the ones I wrote for a commercial Common Lisp compiler. They will make for some very powerful scripting ops.

So how many languages are you using at this moment to write commercial application code? Or do you not actually ship any commercial software. None of this is theoretical My Language Is better Than Your Language to some of us you know. I am using C and C++. Java and Swift for various projects. One is a good 100K+ loc application code base. And porting out some Objective C code that will be useful in Swift. Plus all scripting is supported by embedded JavaScript/ TCL engines. There still does not seem to be a better embedded rule engine than CLIPS. Will need that for next project. Have been looking at Julia. To see if its an improvement over Occam. Looks promising enough to try a proof of concept test. When you have written a few compilers its straightforward to implement useful features in other languages in C / C++. Plus the usual x64/ARM asm when needed. In this case the final code gen stage of one project.

Did I mention all the dev / test tools are written in Python?

So what was that you were saying again? By the sound of it you really dont have a clue about how to write real world large codebase commercial end user software, do you? So I will let you get back to your purely theoretical Language Wars circle jerk. Which is all it is with languages like Rust. Show me something original, useful, then I might take it seriously. When those languages do come alone. Every now and then. I'm the first to sign up. To make my time more productive.

Because some of us have products to ship. That people pay money for.

[fg_swe]

Yeah, Rambling

I currently write code for automotive software, some of which is ASIL-B. I worked on electric/electronic power steerings, which are up to ASIL-D. All in C plus static checkers such as PC Lint and PolySpace. Both tools typically find plenty of issues(index errors, integer under/overflows,...) in the code of experienced engineers. Maybe your car contains this code and your life depends on it.

Apple Swift was inspired by my language

http://sappeur.ddnss.de

Even though Apple made serious shortcuts on efficient Reference Counting (all Swift ARC is MT safe, which is both inefficient and enabling one type of error).

If you want to see some of my source code, please feel free to look here

http://gauss.ddnss.de

[fg_swe]

Automotive and Aerospace Software Safety

I hasten to add that modern software engineering processes (ASPICE, V-Modell etc) have several lines of defense against software engineering errors. Auto drivers do not have to worry too much, neither do AIRBUS passengers or pilots.

First, there is thorough documentation, secondly thorough design steps. Thirdly, upwards the V, there is a cascade of Unit, Software and HIL Test batteries. Even if we did not use static checkers, these comprehensive test efforts would most likely find dangerous bugs.

AIRBUS likewise has a an almost perfect record in both JÄGER90 and commercial airplanes since A310 and later. Not a single loss of aircraft due to flight control software and hardware !

They have even more measures in place, including the use of SPARK Ada. Much better than C.

[mmstick]

Re: Male Cow Stuff....another clueless code kiddie?

Prove to us that a "sloppy programmer" can easily create a memory vulnerability using Rust. Provide the Rust Playground link to your work so that we can evaluate it.

[mmstick]

Re: That google guy, he's never shipped product..a "researcher".

Yelling at clouds won't make technological progress halt just because you're not emotionally ready for the change. Rust is already widely adopted by most organizations that write software today, so it's too late to stop it.

Mozilla detached themselves from managing Rust many years ago. Rust is now managed by the Rust Foundation, which has sponsorships from quite a few high profile companies. Guess who these companies are, and why they're sponsoring it?

You claim that Firefox is the only project that's adopted it, and yet you're commenting on an article about Android that's been using it for a few years now. Microsoft had written the exact same articles about Rust, but I guess Android and Microsoft don't exist in your world view.

Even Linux now has Rust integrated into the kernel with many projects in the Linux space using it, but Linux must be a fictitious project in your eyes. Can't even further that virtually every website is using Rust. AWS, Cloudflare, Fastly, and Discord are all using it.

But by all means, keep grasping at straws to curse at younger generations of software developers, and the decades of programming language research written by researchers since the inception of C. That just makes you a pitiful and unenviable shell of a human being. One of the people responsible for the toxic behavior in software development communities that we're all trying to fix today.

[captain veg]

Android runs better when covered in Rust

Surely *built on* Rust. It's covered in data-harvesting parasites.

-A.

[fg_swe]

Re: Android runs better when covered in Rust

As long as the p........ improve practical computer science, we should applaud them ;-)

[Anonymous Coward]

"C/C++" is not a language

"he means C/C++ – a language" stop right there please: C is a language, C++ is a language, "C and C++" are related languages, but "C/C++" is just management-speak