No privileged base system components at all.
Conversation
Replying to
It's designed around doing that though, which is why they are using namespaces the way that they are. If you just want an Android runtime and apps, you don't need to approach it this way. Can be done like Fuchsia or the original ChromeOS approach which used NaCl not containers.
2
The original ChromeOS approach didn't give Android apps direct kernel access. It compiled them to NaCl apps (would be WebAssembly instead now doesn't make much difference) which have low-level containment for native code and are also run inside the tight browser renderer sandbox.
1
1
Replying to
They were still native code, executing on hardware directly (NaCl is was different than WebAssembly, and also shipped code as native unlike PNaCl which used LLVM IR). It used Chrome infrastructure for the sandboxing but they certainly weren't tied to web content in any way.
2
Replying to
Shipping native code and asking us to trust it rather than sandboxing it is just no.
1
Replying to
It is sandboxed. It runs inside the Chrome renderer sandbox, with even more distrust than the the usual ones since it doesn't count as part of the browser. NaCl / PNaCl / WebAssembly are another layer of security inside the renderer sandbox, rather than full native code exec.
1
The whole point of NaCl was that they came up with a scheme for running native code without arbitrary uncontained code execution. It was still run with the OS sandbox, but the point was not just giving the untrusted code full native code execution inside of that OS sandbox.
1
PNaCl changed it by making it portable, and WebAssembly is effectively the same thing but from scratch with complete portability / avoidance of undefined behavior as a core part of it rather than based on a frozen LLVM IR subset like PNaCl with an attempt to purge those things.
1
ARC is dead though. They gave up on using the strong renderer sandbox + NaCl within that, because they would have had to reimplement the entirety of the Android system APIs in Chrome. They made really good progress but at some point they just decided to take a shortcut instead.
1
It's a whole lot harder to achieve 100% compatibility when you actually have to reimplement the APIs for a strong sandbox vs. just running the *entirety* of Android natively on top of a kernel with Android IPC support and separating it with namespaces and some bridging to host.
Also, it didn't have any direct Linux kernel access, since it was not just in the OS sandbox directly. Apps had to target it as a separate arch (i.e. compile their native code for it). Now, they could use gVisor for the Linux kernel ABI without providing direct kernel access.
1
There were a decent number of apps targeting it, including apps like VLC which is the kind of app that would be most difficult to support it. Apps without native code could trivially run on it. Apps with native code had to build for it and cope with having a subset of Linux APIs.
1
Show replies