For some time already I’m considering different platforms for implementing an app that will run within a browser. This peculiar piece of software has to perform weird things with the user’s workstation and basically requires running native code with administrator privileges. Naturally, I was looking to sandbox it somehow to limit the damage done if a defect crawls in. Runtimes like .NET call the native code ‘unmanaged’ for a reason: if you decided to use native code, you’re on your own.
Yesterday my good friend brought to my attention an interesting project born within Google — the NativeClient (NaCl). The concept these guys are pushing is basically isolating parts of your process within a dedicated address space in a browser. I took a look at the documentation trying to figure out if there’s a detailed explanation of how this is done. Unfortunately, the only thing I found was a video and videos are not really my thing.
Coincidentally, I’ve stumbled upon a blog post with a unsuspicious title ‘What has happened to the segment registers’. (By the way, if you don’t read the LShift blogroll, you are probably missing a lot.) I did some assembly back in high school, so I was interested. If you did that as well, you may remember that the ‘real mode’ is all about setting the segment registers correctly. Not so in ‘protected mode’ — you have to care about GDT, LDT and other weird stuff. What you get in exchange, however, is real isolation between the processes — one process can not uncontrollably use the memory of the another. All books on the subject I’ve seen so far claim that protected mode is the way to go and hand-waive the impure segment-based to rust in peace on a pile of used 8086s.
Turns out that the segment registers didn’t really go anywhere. It’s just that they are rarely used. You still can access this layer of sandboxing and it still works. The isolated code will not be able to access anything besides the assigned segment. The code, however, is free to change the value of his segment register, so special care is needed to prevent this from happening. Both NaCl and VX32 (a general-purpose library built on the same principles) do that for you provided that you do not run dynamic code. I can not really say that I fully understand how this works — VX32 somehow manages to crash if you try to go execute syscall. If you do understand the machinery behind the scenes, please let me know — this is some really interesting stuff.
Where this technique may be useful? It’s hard to say. Mobile devices come to my mind immediately, but it looks like the managed environments are here to stay, at least for the higher end gadgets. However, it’s been a while since I dwelled in the native code land. The tech is indeed cool (the VX32 guys were even able to run Plan 9 kernel in userspace), but the use case eludes me.
What do you guys think?
