Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 13:23 UTC (Fri) by atnot (guest, #124910)
In reply to: Memory Safe Languages in Android 13 (Google security blog) by khim
Parent article: Memory Safe Languages in Android 13 (Google security blog)

I think this is just a case of differing terminology.

> Race condition – concurrent reads/writes to shared memory

This definition is equivalent to what the article and rust land calls a "data race". It's not really worth arguing on vocabulary because there's not really any common agreement on what a lot of these terms mean or what their relation is, as the article points out.

The important thing is just that unlike some languages like C or Go, race conditions in safe java and rust can not cause language-level undefined behavior. They can only cause program-level unexpected or undesirable behavior.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 15:46 UTC (Fri) by marcH (subscriber, #57642) [Link]

BTW java.util.concurrent is a pretty good antidote against race conditions.

I believe the work to create java.util.concurrent eventually prompted this:

https://en.wikipedia.org/wiki/Java_memory_model#Impact

> The Java memory model was the first attempt to provide a comprehensive memory model for a popular programming language.[6] It was justified by the increasing prevalence of concurrent and parallel systems, and the need to provide tools and technologies with clear semantics for such systems. Since then, the need for a memory model has been more widely accepted, with similar semantics being provided for languages such as C++.[7]

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 18:41 UTC (Fri) by matthias (subscriber, #94967) [Link] (7 responses)

> ... race conditions in safe java and rust can not cause language-level undefined behavior.

For java this should be true, but in rust, data races are undefined behavior. However, in safe rust, it is not possible to cause data races. Every reference in safe rust is either read only or unique.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 20:43 UTC (Fri) by atnot (guest, #124910) [Link] (6 responses)

I think we mean the same thing, just with different words. What I mean is that you can create race conditions in both languages, for example by checking the permissions of a file before writing it, or taking a copy of a shared value and then modifying it and writing it back. But unlike e.g. C and Go, these race conditions can not compromise the integrity of the JVM or abstract machine. So they are undefined only in the higher level sense that the application may misbehave in unpredictable ways.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 22:26 UTC (Fri) by riking (subscriber, #95706) [Link] (5 responses)

Easy way to create a "Race condition" (as distinct from a "Data race") in Rust:

- Create a multi-producer, single consumer channel.
- Create two threads with different identities.
- Each thread sends its identity over the channel after it starts.
- Read the first value received from the channel and do something important with it.

The two threads race to be the first to deliver their value. An identical situation in Java is also easy to accomplish.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 12:02 UTC (Mon) by hmh (subscriber, #3838) [Link] (4 responses)

This is not even a bug when the processing order of the messages for the two threads doesn't matter to program correctness -- and it better not matter in any such design. But yeah, it is definitely undefined which thread will get its message processed first. Note that it might not even be racy, but rather system-dependent (where it *always* works out the same way in a given system, but it might change in a future version).

However, what _atnot_ described is known as "TOCTOU", and it is an extremely common race condition that is behind a lot of security vulnerabilities involving filesystems, for example. In this case, the program would be racing whatever else might be trying to manipulate that same filesystem resource. And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 12:22 UTC (Mon) by khim (subscriber, #9252) [Link] (3 responses)

> And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

No. It's possible to do in Rust, but it's not easy (let alone “extremely easy”). If both producer and consumer are in your program then Rust's type system would, usually, stop you (read here about how it does that).

Of course if you would add communication to external systems (use Unix pipes or network for communication between pieces of one program, for example) then all bets are off, but I wouldn't characterise such design as “extremely easy”. Rather I would characterise it as “elaborately created footgun”.

Yes, they are possible, but you have to work to create them.

P.S. And yes, people often complain bitterly about that property of Rust when they invent clever footguns and Rust says it doesn't want to accept these. Just look on how some people avoid race conditions. And weep.

P.S. Actually read the whole thread. Because guy there treats race condition precisely and exactly like other here treat UB: I tested, it worked in C#, why compiler couple make it work for me in Rust? O_PONIES, O_PONIES, and more O_PONIES.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 16:07 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

> > And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

> No. It's possible to do in Rust, but it's not easy (let alone “extremely easy”). If both producer and consumer are in your program then Rust's type system would, usually, stop you (read here about how it does that).

Please. Stop. Engage. Brain. Before. Opening. Mouth.

You clearly don't understand what TOCTOU is (or, more likely, you forgot that was what we were discussing).

The problem is not preventing your program screwing it up. The problem is preventing an *external* *hostile* program taking advantage. If there is an easy way to prevent Rust from screwing *that* up, I'm sure many people will be all ears ... (Other than how I did it years ago in Fortran, files were configured NR&1W, everybody could open the file read-only, but to change it, you had to open it r/w, and then run the entire transaction from scratch.) Just because the Rust compiler blocks two threads in the same program messing up, doesn't mean it'll stop an unrelated trojan barging in on the party ...

Cheers,
Wol

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 17:22 UTC (Mon) by khim (subscriber, #9252) [Link]

> You clearly don't understand what TOCTOU is (or, more likely, you forgot that was what we were discussing).

TOCTOU may happen inside of one program, too. In fact if we are talking about things like Linux kernel then most TOCTOUs which caused security problems, happened inside of kernel, not outside of it.

> Other than how I did it years ago in Fortran, files were configured NR&1W, everybody could open the file read-only, but to change it, you had to open it r/w, and then run the entire transaction from scratch.

Today we have Rwlocks for that and you can [try to] upgrade reader lock to writer lock. But yes, Rust ensures more-or-less what you describe. Just on language level.

Yes, of course, by itself it's not a protection against external actors, but it greatly simplifies code which have to deal with external actors, too.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 18:13 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I mostly find TOCTOU to be an API problem with not covering some use case that *appears* to be supported by a sequence of APIs but is actually wanted to be a single operation. *Most* of the time you can ignore things, but when you can't, it's usually pretty deep down where the operation needs to be addressed (e.g., "overwrite file if contents are different" or "delete if current user owns the file").