It is time to standardize principles and practices for software memory safety

Bounds checking exists at very least since JOVIAL in 1958, or if you consider FORTRAN compilers have add an option for bounds checking for quite some time, 1957.

Here is my favourite quote, every time we discuss bounds checking.

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"

Guess what programming language he is referring to by "1980 language designers and users have not learned this lesson".

> But ... it's Pascal, right? Toy language.

Not really.

It's just out of fashion. But there are really high quality current day implementation, like the one from Embarcadero (i think they acquired Borland a while ago?): https://www.embarcadero.com/products/delphi/features/design

I heard algol had bounds checking somewhere in 60s as an implementation feature. Reportedly customers liked it a lot that the programs don't produce wrong results faster.

> On what sort of machine? What sort of OS?

Just sharing an anecdote: recently, I had to create Linux images for x86 on ARM machine using QEMU. During this process, I discovered that, for example, creation of initrd fails because of memory page size (some code makes assumption about page size and calculates the memory location to access instead of using system interface to discover that location). There's a similar problem when using "locate" utility. Probably a bunch more programs that have been successfully used millions, well, probably trillions times. This manifests itself in QEMU segfaulting when trying to perform these operations.

But, to answer the question: I think, one way to define memory safety is to ensure that the language doesn't have the ability to do I/O to a memory address not obtained through system interface. Not sure if this is too much to ask. Feels like for application development purposes this should be OK, and for system development this obviously will not work (someone has to create the system interface that supplies valid memory addresses).

I think the usual context just requires language soundness; it doesn't depend on having an MMU or anything like that. In particular, protection against:

- out-of-bounds on array read/write

- stack corruption such as overwriting the return address

It doesn't directly say "you can't use C", but achieving this level of soundness in C is quite hard (see sel4 and its Coq proof).

I believe that the parent is talking about how Java, and in turn the JVM, defines its memory model, which describes formally how memory reads and writes occur in the presence of multiple threads of execution. For example, data races are well-defined in Java: Either you read the old or the new value, you'll never read a mix of two values.

Having a well-defined memory model is important when running on infra with very different models, such as x86 and aarch64.

Is it a big difference if you have ValueNotPresentException from nullable unwrap instead of NullPointerException?

Oh, wait, it exists https://docs.oracle.com/javase/8/docs/api/java/util/Optional...

The log4j vulnerability happened because the log4j programmers made an overly generalized "do anything and everything" software. The kind of architecture that is made to be so generic that the software accidentally gains emergent properties (=not thought of/realized/considered execution paths and interactions). Although the desire to write software like that might have arisen under the influence of the object oriented mindset, I'm sure it could have happened in any other language.

> I’d say that despite having good memory safety I would say the JVM’s powerful serialization primitives make me pretty leery of it as far as security goes.

That's a sound deduction. The JVM had such a vulnerability because it's full of ambient authority and rights amplification patterns. More such vulnerabilities probably exist, they're just hard to see.

You can do the same thing in Rust as Log4J.

I haven't tested this code, and definitely don't do this.

This code is intended to lets attackers run any shell command by sending JSON with a "debug_command" field - similar to Log4J, it's a "feature" being misused rather than a memory bug that Rust would catch.

      ```rust
   use serde_json::Value;
   use std::process::Command;
   
   fn process_log_entry(log: &str) {
       //  UNSAFE: Allows command injection
       if let Ok(json) = serde_json::from_str::<Value>(log) {
           if let Some(cmd) = json.get("debug_command") {
               Command::new("sh")
                   .arg("-c")
                   .arg(cmd.as_str().unwrap_or(""))
                   .output()
                   .unwrap();
           }
       }
   }
   ```

The log4j vulnerability was due to Java code, not in the JVM. But I get that people mostly conflate the two.

1. Those fast algorithms that can't be implemented in safe Rust are rare.

2. Even when they exist, Rust lets you use unsafe code but only where needed. It's still much better than having your entire program be unsafe.

3. In practice Rust versions of programs are as fast, if not faster than C/C++ ones.

That assumes that people know what they're doing in C/C++, I've seen just as many bloated codebases in C++ if not more because the defaults for most compilers are not great and it's very easy for things to get out of hand with templates, excessive use of dynamic libraries(which inhibit LTO) or using shared_ptr for everything.

My experience is that Rust guides you towards defaults that tend to not hit those things and for the cases where you really do need that fine grained control unsafe blocks with direct pointer access are available(and I've used them when needed).

Once you know how Rust works it is likely your Rust code will be faster than C/C++ with less effort. I can say this because I was using C++ for a long time since Visual C++ 6.0 and moved to Rust recently about 3 years ago.

One of the reason is you get the whole program optimization automatically in Rust while C/C++ you need to use put the function that need to be inline in the header or enable LTO at the link time. Bound checking in Rust that people keep using as an example for performance problem is not actually a problem. For example, if you need to access the same index multiple times Rust will perform bound-checking only on the first access (e.g. https://play.rust-lang.org/?version=stable&mode=release&edit...).

Borrow checker is your friend, not an enemy once you know how work with it.

> not implementable in safe rust

This is moving the goalposts. "Safe rust" isn't a distinct language. The unsafe escape hatch is there to make sure that all programs can be implemented safely.

> a somewhat broken async situation

Isn't Rusts's async situation "somewhat broken" in the exact same way the C++'s async situation is?

C++ often perform significantly worse than assembly for many kinds of code where you care a lot about performance. You can bring that performance closer together with bits of ASM in your C++ but at that point you might as well use ASM.

Exactly, and also MIRI catches all of these, so with a tiny little extra effort world is in order again.

Moreover, if I remember correctly, they all are made possible by a single (long-standing) compiler bug that eventually will be fixed.

Previously discussed: https://news.ycombinator.com/item?id=39440808

I think this mindset is the big difference. We're not perfect, but we're working on it.

Good luck getting those in power to agree to that.

Meanwhile, everything else passes under the guise of "safety and security".

The governments will always have a way in if you're a target.

Meanwhile the rest of the population gets pushed towards authoritarian dystopia.

Users should have control and trust in their devices.

I think that already went away once they started adding spyware ("telemetry" being the usual euphemism) and forced automatic updates ("remotely compromised", as you put it.)

A rewrite isn't strictly necessary. It should be enough if AI can find errors, doesn't even need to be very precise.

If it is too big just zip it and feed chunks of the resulting zipfile to the AI. AI can do anything, right?

Easy, triple the hardware requirements and don't talk to any hardware because if you do you'll have to mess with buffers in a non approved way.