Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

Post reply on HN
Print view View original

411–420 of 430 posts

Re: Rust in Android: move fast and fix things

#411

Post by ksec »

kccqzy wrote: post #385
LexiMax wrote: post #354

Earlier quoted context omitted.

In my experience, the loudest critics of Rust I have heard are actually seasoned C and C++ developers who are incredibly good at one or both languages, but know almost nothing outside it. On one hand, C++ is an incredibly complicated language that one can invest considerable amounts of time into. It also used to occupy a unique niche where you get tons of abstraction features yet as much blazing speed as you care to…

> what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades That’s certainly not the case for C++. The C++ language has evolved quickly, with a release every three years or so. One could coast, but they would be writing outdated C++ that no newcomer likes. That is, the entire organization needs to also coast for this behavior to be viable. Instead I see…

>Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages....

>They whine because they think Zig or Nim should take the place of Rust.

How about because Rust Evangelism Strikeforce go after other language first? Every time a language in the same space comes they get asked if they are memory safe?

Things have died down now, doesn't mean it didn't happen.

Re: Rust in Android: move fast and fix things

#412

Post by tcfhgj »

ksec wrote: post #411
kccqzy wrote: post #385

Earlier quoted context omitted.

> what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades That’s certainly not the case for C++. The C++ language has evolved quickly, with a release every three years or so. One could coast, but they would be writing outdated C++ that no newcomer likes. That is, the entire organization needs to also coast for this behavior to be viable. Instead I see…

>Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages.... >They whine because they think Zig or Nim should take the place of Rust. How about because Rust Evangelism Strikeforce go after other language first? Every time a language in the same space comes they get asked if they are memory safe? Things have died down now, doesn't mean it didn't happen.

> Every time a language in the same space comes they get asked if they are memory safe?

So what?

It might be shocking for you, but every new messenger gets asked if it supports e2ee these days.

Why shouldn't people want to know about the availability of a massive advancement in the space of system programming languages?

Re: Rust in Android: move fast and fix things

#413

Post by Zambyte »

pjmlp wrote: post #316
Zambyte wrote: post #162

Earlier quoted context omitted.

Zig in spirit is essentially Go without GC. If GC is not reasonable for your usecase Zig seems like an awesome choice. Unfortunately it's probably about 5 to 10 years out from being stable enough for most people being able to write serious applications in it though (notable exceptions being Bun and Ghostty, but they have solid effort behind them keeping them up to date with Zig).

More like Modula-2 in C clothing, given the safety guarantees.

If you're focusing on safety guarantees, sure. If you measure by safety checks included by default instead, it actually has more safety checks than Go (in particular, safety checked numeric operations for overflow).

The other big thing that makes it spiritually like Go is that you follow the same pattern of: allocate resource, immediately defer deallocation.

Re: Rust in Android: move fast and fix things

#414

Post by ksec »

tcfhgj wrote: post #412
ksec wrote: post #411

Earlier quoted context omitted.

>Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages.... >They whine because they think Zig or Nim should take the place of Rust. How about because Rust Evangelism Strikeforce go after other language first? Every time a language in the same space comes they get asked if they are memory safe? Things have died down now, doesn't mean it didn't happen.

> Every time a language in the same space comes they get asked if they are memory safe? So what? It might be shocking for you, but every new messenger gets asked if it supports e2ee these days. Why shouldn't people want to know about the availability of a massive advancement in the space of system programming languages?

And yet at the same time naming Ada is forbidden?

Re: Rust in Android: move fast and fix things

#415

Post by androidcode »

pjmlp wrote: post #328
androidcode wrote: post #325

Earlier quoted context omitted.

Yes, so something like a modernization profile for C++ would make it easier to enforce, and would not require external tools. But it ultimately does not change that C++ is not C, and that the blog is deeply misleading. Nor does it change that Google Android source code appears to have significant issues. > as if there isn't any other memory safe language. But Rust is obviously not a memory safe programming language.…

With that line of argumentation there are no safe languages, we should all go back to Assembly.

Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust. Consider for instance a standard library implementation of a collection in Java and Rust. In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.

This is not a theoretical exercise. https://materialize.com/blog/rust-concurrency-bug-unbounded-... .

AWS started an initiative to formally verify the Rust standard library, based on volunteer effort and maybe bounties. I think that is interesting, but I looked once at one of the issues for tracking what they had verified, and as I remember, even though they had marked it as fully verified, the main person verifying had called to attention in a post that he had not verified everything that the issue covered.

And even for memory-unsafe languages like Rust, there are trade-offs.

Re: Rust in Android: move fast and fix things

#416

Post by androidcode »

aw1621107 wrote: post #327
androidcode wrote: post #325

Earlier quoted context omitted.

Yes, so something like a modernization profile for C++ would make it easier to enforce, and would not require external tools. But it ultimately does not change that C++ is not C, and that the blog is deeply misleading. Nor does it change that Google Android source code appears to have significant issues. > as if there isn't any other memory safe language. But Rust is obviously not a memory safe programming language.…

> But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear. Everything else aside, why is no_std included here?

no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.

And one does not even need esoteric code to trigger stack-overflows, dependent on coding style, a simple recursive call that has bugs like proper lack of constraints relative to resources or bugged infinite recursive calls without tail-call optimization, can do it.

Re: Rust in Android: move fast and fix things

#417

Post by LexiMax »

ksec wrote: post #411
kccqzy wrote: post #385

Earlier quoted context omitted.

> what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades That’s certainly not the case for C++. The C++ language has evolved quickly, with a release every three years or so. One could coast, but they would be writing outdated C++ that no newcomer likes. That is, the entire organization needs to also coast for this behavior to be viable. Instead I see…

>Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages.... >They whine because they think Zig or Nim should take the place of Rust. How about because Rust Evangelism Strikeforce go after other language first? Every time a language in the same space comes they get asked if they are memory safe? Things have died down now, doesn't mean it didn't happen.

> Things have died down now, doesn't mean it didn't happen.

I have some bad news for you. In the early 90's, C++ _was_ that language. Not only that, but at the time a lot of the reactionary criticisms of C++ by annoyed C developers had a lot more weight to them.

- C++ was slower than C, because the costs of vtables and exceptions was a lot larger and compilers weren't as good at optimizing.

- C++ was bug-ridden, both because it was easy to accidentally misuse the language, but also because compilers were simply buggy due to the complexity of the language.

- Many of the STL containers you know and love were missing from pre-standard C++, and even afterwards its implementation was commonly subpar, leading developers to either use their compiler-specific proprietary containers or roll their own.

- Streams were often the only reliable thing in the C++ standard library. It also ballooned compile times to the point of being outright banned from many codebases.

- Don't get me started on the utter nightmare that was sifting through compiler errors through misuse of templates...

So yeah, I don't want to hear other C++ developers whine about how annoying Rust developers are. We were just as annoying back in the day, with a worse language. Linus banned C++ from the kernel, and honestly he was 100% right to do so at the time.

Re: Rust in Android: move fast and fix things

#418

Post by aw1621107 »

androidcode wrote: post #415
pjmlp wrote: post #328

Earlier quoted context omitted.

With that line of argumentation there are no safe languages, we should all go back to Assembly.

Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust. Consider for instance a standard library implementation of a collection in Java and Rust. In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the…

> Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust.

What definition of memory safety are you using where (supposed) "necessity" and "prevalence" are factors, and at what thresholds for those two factors do languages cross from unsafe to safe or vice versa?

> In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.

So you have Rust, which uses unsafe code for performant collections, and Java, which uses unsafe code via its JIT for performant collections. I'm not sure I see a substantial difference here.

Re: Rust in Android: move fast and fix things

#419

Post by josephg »

ActorNightly wrote: post #382
kibwen wrote: post #167

Earlier quoted context omitted.

> That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does. Making a language with memory-safe pointers isn't hard. Making a language with memory-safe pointers that doesn't rely on sandboxing, a virtual machine, or other dynamic checks which produce runtime overhead--thereby disqualifying one from being considered for this domain in the first place--is n…

Rust has things that have dynamic runtime check overhead that are often used. Reference counters, array size, e.t.c You have to have runtime checks because of Rice's theorem. The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold. But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an option…

So your claim is that sufficiently careful C is just as safe as rust?

Seems like a pretty wild claim to make in the comment thread of this article. Google has some of the most careful engineers in the business. They use valgrind & ubsan & friends religiously. And yet this is their conclusion:

> Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.

C is not as memory safe as rust. And it cannot be made as safe as rust with a few bolted on tools and programming tricks.

Re: Rust in Android: move fast and fix things

#420

Post by aw1621107 »

androidcode wrote: post #416
aw1621107 wrote: post #327

Earlier quoted context omitted.

> But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear. Everything else aside, why is no_std included here?

no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior. And one does not even need esoteric code to trigger stack-overflows, dependent on coding style, a simple recursive call that has bugs like proper lack of c…

> no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.

I think you're technically correct, though I also think the picture is a bit more complicated than you paint it. From my understanding, stack overflow protection needs cooperation between (at least) a language, its runtime (if present), and the environment the program is run in. In other words, I'm not sure any language can "protect the stack completely" without knowledge of the environment it's going to be run in, so at least technically speaking I don't think Rust is any different here.

That being said, rustc will insert stack probes even when compiling with no_std, so in environments where stack probes are sufficient to protect against stack overflow/stack clashes no_std is safe with respect to that particular issue.

For example, this short program:

    #![no_std]
    #[inline(never)]
    pub fn f() -> u8 {
        let v: [u8; 16384] = [1; 16384];
        v.iter().sum()
    }
Produces stack probes on e.g., x86_64-unknown-linux-gnu [0]:

    example::f::hb88315ca0b28f303:
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        push    rax
        lea     rdi, [rsp + 8]
        mov     edx, 16384
        mov     esi, 1
        call    qword ptr [rip + memset@GOTPCREL]
[0]: https://rust.godbolt.org/z/rcdvj8j4K
Post reply on HN