Because Linux, the kernel, as well as other Unixes, don't have the right abstractions to easily build these. And there's all the old cruft.
Just look at what Android had to do to implement a secure platform with somewhat of a well defined non-1980's OS API - it basically removed the Unix part of the OS and built a Microkernel-like thing on top of it.
Driver support would be a very important part though.
> Just look at what Android had to do to implement a secure platform with somewhat of a well defined non-1980's OS API - it basically removed the Unix part of the OS and built a Microkernel-like thing on top of it.
...Huh? Pretty much all Android adds to the kernel is Binder, which is really a performance optimization for it's version of IPC, which today has equivalents that mean it probably wouldn't need it's own version now if it didn't need compatibility.
The security model allows native apps, which have access to all the normal libc, or even direct syscalls. Some hardware access is marshalled through userspace daemons, which may implement security for things like camera/microphone access, but that's been a pretty common thing on other unix-style OSs for ages.
Though the separation of each app into it's own UID might not have been the original intent, but it seems to work implemented with those same unix capabilities.
Yeah, most apps probably don't use POSIX APIs directly, and instead the java Android APIs, but they are very much build on top of the "crufty 1980s OS APIs", rather than bypassing them.
Android blocks most of Linux syscalls with seccomp. They make heavy usage of SELinux.
Binder is not just a simple IPC system. It requires userspace parts which aren't even the parties who are talking through IPC. Like you said it has lots of performance optimizations, and that requires it hooking up to a number of kernel subsystems. At the beginning it was met with a lot of resistance from kernel maintarners when tried to be merged.
Why did Google came up with it? When talking about the 'Android sandbox' people usually talk about how Android gives each app an different uid/gid. But that's just the beginning of the story. It wasn't enough for sandboxing needs since the beginning. Thats why they took the binder idea from BeOS and used on Android.
Since then Google has blocked everything. Native code is needed on any practical system, but today's native code has access mostly to nothing, just the common needs to run (like libc which is used due backward compatibility). The proper way to get something is through Binder (and even that is fine-grained controlled on a per process basis).
Linux and Unixes in general don't implement true capabilities. Android does through Binder, but since Binder lives “inside Linux” everything else has to be blocked to make these capabilities useful.
> Some hardware access is marshalled through userspace daemons
Most of stuff are, at least initially, orchestrated through userspace software - daemons like you said, but mostly HALs (which are also daemons).
The main takeaway is that binder is _the core_ of Android userspace. It's tightly integrated with SELinux and everything passes through it at some point. Permissions are enforced through it. In the end, the whole “binder subsystem” is architectured like a Microkernel system.
Eh the system described in the post is mostly about taking away (no filesystem access, no multiple IPC methods, no X11...) All new required software seems to be only userspace:
- New IPC system: presumably it's abstracted, so can use any existing IPC for implementation. Or, purely as optimization, use Android's Binder or bring back bus1 (it was such a great idea)
- Document Database: pure userspace; in the most extreme case use raw block device
- Compositor / WM / Windows: this was always userspace already
- Rebuild the apps: userspace as well
Then once you new fancy APIs are ready, you use seccomp and/or per-app users and/or namespaces to isolate apps from everything except the few things people want.
> the system described in the post is mostly about taking away
I agree.
The hard part is, as usual, on the details. How do you take away stuff so that you still end up with an usable general purpose OS? That's definitely not easy, specially if you want to make it in a proper way, without hacking things up.
For example, suppose you make the decision to use the Linux kernel, which is a good one - you get driver support, networking, filesystems, and all the good stuff and general primitives for a common OS of today.. Given that what one wants is to remove stuff, in order to make that secure (which is requirement) you'd need to isolate and block everything because on Linux everything is accessible to a process by default, and the common primitives for control are very basic - you'd have to do a _lot_ of work in userspace to block it. It would contaminate your userspace architecture with details and stuff. And then you'd probably end up needing something to make the userspace parts able to communicate with each other, like Binder on Androids case (see my other comment in this thread).
Because Linux, the kernel, as well as other Unixes, don't have the right abstractions to easily build these. And there's all the old cruft.
Just look at what Android had to do to implement a secure platform with somewhat of a well defined non-1980's OS API - it basically removed the Unix part of the OS and built a Microkernel-like thing on top of it.
Driver support would be a very important part though.
> Just look at what Android had to do to implement a secure platform with somewhat of a well defined non-1980's OS API - it basically removed the Unix part of the OS and built a Microkernel-like thing on top of it.
...Huh? Pretty much all Android adds to the kernel is Binder, which is really a performance optimization for it's version of IPC, which today has equivalents that mean it probably wouldn't need it's own version now if it didn't need compatibility.
The security model allows native apps, which have access to all the normal libc, or even direct syscalls. Some hardware access is marshalled through userspace daemons, which may implement security for things like camera/microphone access, but that's been a pretty common thing on other unix-style OSs for ages.
Though the separation of each app into it's own UID might not have been the original intent, but it seems to work implemented with those same unix capabilities.
Yeah, most apps probably don't use POSIX APIs directly, and instead the java Android APIs, but they are very much build on top of the "crufty 1980s OS APIs", rather than bypassing them.
Android blocks most of Linux syscalls with seccomp. They make heavy usage of SELinux.
Binder is not just a simple IPC system. It requires userspace parts which aren't even the parties who are talking through IPC. Like you said it has lots of performance optimizations, and that requires it hooking up to a number of kernel subsystems. At the beginning it was met with a lot of resistance from kernel maintarners when tried to be merged.
Why did Google came up with it? When talking about the 'Android sandbox' people usually talk about how Android gives each app an different uid/gid. But that's just the beginning of the story. It wasn't enough for sandboxing needs since the beginning. Thats why they took the binder idea from BeOS and used on Android.
Since then Google has blocked everything. Native code is needed on any practical system, but today's native code has access mostly to nothing, just the common needs to run (like libc which is used due backward compatibility). The proper way to get something is through Binder (and even that is fine-grained controlled on a per process basis).
Linux and Unixes in general don't implement true capabilities. Android does through Binder, but since Binder lives “inside Linux” everything else has to be blocked to make these capabilities useful.
> Some hardware access is marshalled through userspace daemons
Most of stuff are, at least initially, orchestrated through userspace software - daemons like you said, but mostly HALs (which are also daemons).
The main takeaway is that binder is _the core_ of Android userspace. It's tightly integrated with SELinux and everything passes through it at some point. Permissions are enforced through it. In the end, the whole “binder subsystem” is architectured like a Microkernel system.
3 replies →
Eh the system described in the post is mostly about taking away (no filesystem access, no multiple IPC methods, no X11...) All new required software seems to be only userspace:
- New IPC system: presumably it's abstracted, so can use any existing IPC for implementation. Or, purely as optimization, use Android's Binder or bring back bus1 (it was such a great idea)
- Document Database: pure userspace; in the most extreme case use raw block device
- Compositor / WM / Windows: this was always userspace already
- Rebuild the apps: userspace as well
Then once you new fancy APIs are ready, you use seccomp and/or per-app users and/or namespaces to isolate apps from everything except the few things people want.
> the system described in the post is mostly about taking away
I agree.
The hard part is, as usual, on the details. How do you take away stuff so that you still end up with an usable general purpose OS? That's definitely not easy, specially if you want to make it in a proper way, without hacking things up.
For example, suppose you make the decision to use the Linux kernel, which is a good one - you get driver support, networking, filesystems, and all the good stuff and general primitives for a common OS of today.. Given that what one wants is to remove stuff, in order to make that secure (which is requirement) you'd need to isolate and block everything because on Linux everything is accessible to a process by default, and the common primitives for control are very basic - you'd have to do a _lot_ of work in userspace to block it. It would contaminate your userspace architecture with details and stuff. And then you'd probably end up needing something to make the userspace parts able to communicate with each other, like Binder on Androids case (see my other comment in this thread).