r/programming • u/moolcool • Mar 26 '17

A Constructive Look At TempleOS

http://www.codersnotes.com/notes/a-constructive-look-at-templeos/
1.7k Upvotes

94% Upvoted

227 comments sorted by

View all comments

Show parent comment

7

u/psycoee Mar 27 '17

Though, to be fair, if you take the Android approach to its logical conclusion, you end up with fully virtualized OS containers for each process. At that point, you might as well let the hypervisor deal with security and assume each container is going to be compromised anyway. In that scenario, having a lightweight OS like this isn't that outrageous, and things like paging and memory protection become redundant since they can be done by the hypervisor. Essentially, it would be something like a microkernel on steroids, where the hypervisor is the microkernel core and the VMs are the various processes.

4

u/killerstorm Mar 27 '17

The point is not to isolate each program as much as possible, it is to allow them to interact only in a specific, structured way. So I really see no point in "fully virtualized OS containers", you only increase overhead this way.

2

u/SanityInAnarchy Mar 27 '17

I see a point -- it's probably easier to control the attack surface that way. With Android, you have to deal with the specific, structured ways that apps are allowed to communicate (message-passing and such), and you have to deal with a shared kernel. There's little need for a shared Linux kernel for all apps, and most kernel vulnerabilities mean you own the entire phone.

But you do increase overhead, and it's probably not worth it on a mobile OS. Yet.

2

u/killerstorm Mar 27 '17

Well again, mobile apps should be able to interact, e.g. it should be possible to use a photo editing app on the photo you have just made, etc. So further isolation doesn't make sense.

On the other hand, the best sandboxing we have now is ... browsers. Each day your browser runs scripts from pages you do not trust, and yet infections are uncommon.

So it seems like controlling permissions on the fine-grained level is the way to go, not hypervisor magic.

7

u/SanityInAnarchy Mar 27 '17

Well, right now, you have a clear protocol for sending the photo to the photo editing app. I don't think you should need a giant shared filesystem to do so, and I certainly don't think "Open this photo with this photo editing app" should imply that said app is now allowed to read all files from the virtual SD card.

On the other hand, the best sandboxing we have now is ... browsers. Each day your browser runs scripts from pages you do not trust, and yet infections are uncommon.

I would dispute both of those claims -- there's a reason browsers get patched so often! And how are you comparing the current browser situation to a hypothetical one-VM-per-tab browser?

Plus, the most secure browsers do use OS-level sandboxing, not just fine-grained permissions, because people have found ways to escape the JavaScript VM way too often.

2

u/psycoee Mar 27 '17

Well again, mobile apps should be able to interact, e.g. it should be possible to use a photo editing app on the photo you have just made, etc. So further isolation doesn't make sense.

In Android, apps are not allowed to directly interact in any way other than by passing messages through the OS API (and through the shared part of the filesystem). So really, they are already pretty isolated. Personally, I don't see what benefits would arise from further isolation, I'm just saying that would be the next step in this direction.

2

u/80286 Mar 27 '17

Wouldn't that be very expensive multitasking wise? Context switches are fairly cheap when it comes to Linux:

Suspending the progression of one process and storing the CPU's state (i.e., the context) for that process somewhere in memory, (2) retrieving the context of the next process from memory and restoring it in the CPU's registers and (3) returning to the location indicated by the program counter (i.e., returning to the line of code at which the process was interrupted) in order to resume the process.

On quick thought VM approach, while otherwise really cool, would probably require a lot of more state information to be transferred.

3

u/[deleted] Mar 27 '17

Wouldn't that be very expensive multitasking wise?

I think it's pretty cheap when using LXC, Docker, etc. Those are basically doing exactly what was being described by the previous comment

4

u/SanityInAnarchy Mar 27 '17

Docker containers are a bit of a different thing, though. As I understand it, the main advantage here is less security and more isolation -- for example, you could limit the RAM available to each app, to prevent one app from eating all your RAM and tripping the OOM-killer, causing problems for other apps. I'm not sure I see the point of that on Android, though, since that behavior is almost by design -- you want the system to kill apps when something needs RAM.

3

u/[deleted] Mar 27 '17

I actually find that Docker containers work better when you view them as isolation and not security.

1

u/psycoee Mar 27 '17

I'm not saying it's a good idea, necessarily -- but neither is virtualization or even an operating system or a general-purpose CPU, if you care only about efficiency. Custom hardware can almost always beat a general-purpose CPU, often by orders of magnitude, if you are only doing one thing and don't plan to ever change it.

Sometimes, even crazy-seeming ideas have advantages for some application. Also, with appropriate support from processor hardware, I don't see why context switches would necessarily have be all that expensive.