[white-flame]

The real problem is deeper than this. The actual question to ask is:

"What if we just stopped distributing and blindly executing untrusted binary blobs?"

A trusted compiler in the OS, and some set of intermediate representations for code distribution would solve a massive amount of security issues, increase compatibility, and allow for future performance increases and disallowing suspect code patterns (spectre, rowhammer, etc). Specializing programs at install time for the local hardware makes way more sense than being locked into hardware machine code compatibility.

[tsimionescu]

That does nothing to fix the vast majority of security issues, which are caused by trusted but not memory safe programs running on untrusted input.

It's also an extremely unrealistic goal. First of all, you run into a massive problem with companies and copyright. Second of all, it will be very hard to convince users that it's normal for their Chrome installation to take half an hour or more while using their CPU at 100% the whole time.

[bawolff]

I feel like you might as well ask "why not world peace"?

There are a huge number of practical issues to be solved to make that be viable.

[grayhatter]

could you list a few of the problems you predict?

[Taikonerd]

The VST Lab at Princeton works on this sort of problem: https://vst.cs.princeton.edu/

"The Verified Software Toolchain project assures with machine-checked proofs that the assertions claimed at the top of the toolchain really hold in the machine-language program, running in the operating-system context."

Some of the same researchers worked on TAL (typed assembly language), which sounds like it could be one of the "intermediate representations" you mentioned.

[transpute]

For a while, Apple required apps to be submitted as bitcode (LLVM IR) to the App Store, where they would be converted to x86 or Arm machine code during device install. They stopped that a couple of years ago, after migration to Apple Silicon.

[refulgentis]

Apple used to require bitcode (LLVM IR) for App Store submissions.

Rest is interesting, nothing was done on install, it wasn't converted or anything to machine code.

In fact, in practice, it never ended up being used.

Well, that's not particularly relevant: the idea was never to do something on device anyway.

Really excellent post here summarizing that I can vouch for: https://stackoverflow.com/questions/72543728/xcode-14-deprec...

[transpute]

Thanks for the correction and link. Relevant to the comment above about binary blobs:

> The idea to have apps in a CPU neutral form available on the app store is not a bad one; that's why Android chose Java Byte Code (JBC). Yet JBC is a pretty stable representation that is well documented and understood, Bitcode isn't. Also on Android the device itself transforms JBC to CPU code (AOT nowadays).

[kbolino]

The general idea is correct, but a rather significant detail is not.

Android did not choose Java bytecode, it chose Dalvik bytecode [1]. This was done for several reasons, but at a high level, Dalvik bytecode more closely matches how real computers work while Java bytecode targets a more abstract virtual machine. This result is that Dalvik bytecode is easier to transform into machine code, and more optimizations are done in the source code -> bytecode phase rather than the bytecode -> machine code phase, relative to Java bytecode.

[1]: https://source.android.com/docs/core/runtime/dalvik-bytecode

[transpute]

Thanks for the additional detail, https://en.wikipedia.org/wiki/Dalvik_(software)

> Programs for Android are commonly written in Java and compiled to bytecode for the Java Virtual Machine, which is then translated to Dalvik bytecode.. The successor of Dalvik is Android Runtime (ART), which uses the same bytecode and .dex files (but not .odex files), with the succession aiming at performance improvements.

[arbitrandomuser]

How did that work though ? Isn't bitcode tied to a target triplet ?

[saagarjha]

It didn’t. Bitcode was only used for watchOS compatibility.

[saagarjha]

Bitcode was never required for app submissions on macOS. It also was never portable across architectures.

[watt]

There is a rule that if somebody poses this hypothetical with the word "just" in it, they have signed themselves up to go and implement it.

So, congratulations, take it and run with it.

[pabs3]

> "What if we just stopped distributing and blindly executing untrusted binary blobs?"

You can do that right now with open source software and Bootstrappable Builds.

https://bootstrappable.org/ https://lwn.net/Articles/983340/