Hacker News Reader

Comment by quotemstr | Hacker News Reader

Memory unsafe language strikes again. How much longer are we going to put up with this?

Forever. Computers are fundamentally unsafe if you tell them to do something you shouldn't have. That's true for every language which has ever been useful.

Formal verification is a thing. Good architectures make undesirable action rare. What's the last time you heard about a worm that spreads from one Android phone to the next, without the owners realizing it?

Given that the majority of android phones have dozens of well known security flaws (because they don't get updates, or get them very late), it's kinda weird they're not all one massive botnet. Why is that?

Mostly because the underlying design makes that difficult. On a traditional desktop an application running as root can do anything, and one running as user can do slightly less than everything. On Android running as root doesn't even exist as a function, and running as user comes with significant limitations enforced structurally by low level SELinux code in the kernel and OS. Android malware can't infect an existing application because the OS both segregates their storage and verifies code signatures.

TPMs take this a step further and create not only logical but physical separation between the main CPU and many cryptographic functions.

Exploits still happen but you need a much longer chain of vulnerabilities to pull it off.

Are you claiming the entirety of Android is formally verified?

Do you have links to those papers?

No, I'm claiming Android has good architecture. If you combined good arch with verification then exploits would be very rare indeed.

This isn’t a meaningful response: “the computer does what you tell it to do” doesn’t mean the same thing as “the computer ends up in an exploitable state when you don’t tell it to do the right thing.”

Yet computers necessarily end up in an exploitable state when you don't tell them to do the right thing. Your back-end is written in Rust? If you don't do your auth checks right, one user can delete another user's content.

Sure, but given a fixed probability of introducing a bug at each possible place, "doing an auth check correctly" has much less probability of being buggy than "doing every memory allocation correctly" because it happens in several magnitudes less places.

No, not necessarily: Rust is by no means the first language to prevent missing bounds checks from becoming exploitable memory unsafety, as just one small example.

All programs are exploitable; the objective is to limit the nature and scope of their exploitability.

Just because we can’t go 100% safe, we shouldn’t even try? That’s a logical fallacy right there.

I'm not saying we shouldn't make safer languages. Rust is okay.

This comment adds nothing tbh; you're mentioning a known problem, but repeating the problem and asking open-ended questions isn't going to solve it. The solutions are there and people are working on them, but this isn't an overnight change.

> The solutions are there and people are working on them

People keep writing new programs in C.

What other options are there?

It's the only systems level language with a formally verified compiler afaik.

rust is a no go because you can't trust the compiler's output (remember, we can't trust people to write correct code, so we obviously can't trust the compiler writers either).

Both formally proven compilers and black-box SMT-based translation verification are a thing. Rust is not there yet but both exist for C.

The vast majority of C programmers do not use a formally verified C compiler, and most of them wouldn't care about that anyway.

From a security perspective, demanding a formally verified C compiler is rearranging the deck chairs on the Titanic. Switching to a safer language like Rust will do much more to improve security, even if the compiler is not verified.

The biggest formally verified program is tiny compared to your regular software suit. That method simply doesn’t scale. Also, it “trusts the hardware” which itself can be (surprisingly) buggy. So there is no 100% safe solution, should we not even try to better our softwares then?

Trusting trust is an interesting paper, but it was never meant as a gotcha, it was meant as a “don’t forget to look at the whole picture from time to time”.

Xorg is a "new program"?

> People keep writing new programs in C.

And you plan to stop me?

Stop lamenting and help X.org, i am pretty sure they have nothing against if you re-implement stuff in rust.

Also, why have you forgot telling linus in 1991, that he should implement linux in something like ADA?

Until security liabilty clauses affect all kind of software, just like they affect physical goods.

If people don't put up with buying a defect pair of shoes, they should behave the same towards software.

> How much longer are we going to put up with this?

Until you rewrite it all in rust

Memory safe languages rely on someone else's software and someone else's compiler/interpreter. Rust and go are memory safe languages because their compiler are (said to be) checking all memory usage either statically or dynamically. It's still software written by someone, running on hardware designed by someone. If I write software in assembler I can just blame myself and the hardware. If I do it in C I can blame myself, the hardware, the compiler and the libraries. If I do it in Java I need to add the JRE and all the Java libraries, plus C etc.

Memory safeness is just an illusion to me or a way to avoid responsibilities in case of issues.

And yet companies like Google have reported significant drops in memory related vulnerabilities.

I wonder if there ever could be a C compiler doing all those checks. What is so radically different about Rust?

As a single example: C’s semantics prevent perfect alias analysis, meaning that a C compiler (no matter how smart) can never provide many of Rust’s basic guarantees without significantly altering the C language.

The lifetime analysis is only possible in Rust because Rust has lifetimes. Even if you write a toy Rust program where you didn't apparently write any lifetimes, they were implied and the implied lifetimes were checked - the language was constrained by the fact you didn't specify a lifetime and so the implied lifetime was checked, whereas in C you can't express the lifetime and so it can't be checked.

The most glorious example of this is comparing C23's #embed with Rust's include_bytes! macro. These are both ways to include a file full of data into your program - which if you're a C programmer you will know was really annoying to do cross-platform before #embed

In C23 the data is just some literals like 1, 86, 69, 204 that are promised to be one unsigned byte each and you do with them whatever you want. How long do they live? -shrug- in some sense forever, but, then again maybe not, it depends.

But in Rust it's specifically &'static [u8; N] -- a reference to an array of N bytes which has the 'static lifetime, it lives potentially for the life of your program.

Blaming you for unsafe code doesn't make code safer. Better systems over personal blame.

Safe languages have restrictions like immutability, garbage collection, or "one mutator at a time" (to ensure temporal safety) outside of deliberately-awkward escape hatches (some unsafe). These tradeoffs are often workable, but some applications require no GC pauses, or placement initialization and non-allocating intrusive linked lists, which can make languages with ergonomic manual memory management a better choice for those use cases. "Safe languages are better than having to write correct code" is a thought-terminating cliche that dismisses the complex tradeoffs and limitations of safe languages.

> If I do it in C, I can only blame myself.

Have you considered the fact that the chances that a single developer messes up memory management in an application with thousands of malloc/free/strcpy/strcat/sprintf are much higher than the chances that something breaks in a compiler that took smart people years to build just to solve the problem of memory management?

Of course, if it breaks in C you can only blame yourself. But, in my opinion, it's better to blame the compiler/VM e.g. once a year, rather than blaming oneself once a week.

Yes, that's exactly why i have my nuclear reactor at home. I don't trust anybody else to run one.

Ever heard of the concept called "abstraction" and "separation of concerns"?

Reply on news.ycombinator.com