How to Run POSIX Apps in a Minimal Picoprocess Jon Howell, Bryan Parno, John R
Total Page：16
File Type：pdf, Size：1020Kb
How to Run POSIX Apps in a Minimal Picoprocess Jon Howell, Bryan Parno, John R. Douceur Microsoft Research, Redmond, WA Abstract Libraries We envision a future where Web, mobile, and desktop Application Function # Examples applications are delivered as isolated, complete software Abiword word processor 63 Pango,Freetype stacks to a minimal, secure client host. This shift imbues Gimp raster graphics 55 Gtk,Gdk Gnucash personal finances 101 Gnome,Enchant app vendors with full autonomy to maintain their apps’ Gnumeric spreadsheet 54 Gtk,Gdk integrity. Achieving this goal requires shifting complex Hyperoid video game 6 svgalib behavior out of the client platform and into the vendors’ Inkscape vector drawing 96 Magick,Gnome isolated apps. We ported rich, interactive POSIX apps, Marble 3D globe 73 KDE, Qt such as Gimp and Inkscape, to a spartan host platform. Midori HTML/JS renderer 74 webkit We describe this effort in sufficient detail to support re- producibility. Table 1: A variety of rich, functional apps transplanted to run in a minimal native picoprocess. While these 1 Introduction apps are nearly fully functional, plugins that depend on fork() are not yet supported (§3.9). Numerous academic systems [5, 11, 13, 15, 19, 22, 25–28, 31] and deployed systems [1–3, 23] have started pushing towards a world in which Web, mobile, and multaneously [16]. It pushes the minimal client host in- desktop applications are strongly isolated by the client terface to an extreme, proposing a client host without kernel. A common theme in this work is that guarantee- TCP, a file system or even storage, and with a UI con- ing strong isolation requires simplifying the client, since strained to simple pixel blitting (i.e., copying pixel arrays complexity tends to breed vulnerability. to the screen). In support of rich apps, Embassies’s mini- Complexity evicted from the client kernel takes up res- mal interface specifies execution of native binary code. idence in the apps themselves. This shift is beneficial: It Native code is an important practical choice, because, lets each app vendor decide independently which com- we assert, it is the lack of native code that has forced plexity is worth the risk of vulnerability, and one ven- each prior system based on language safety to evolve a dor’s decision in favor of complexity does not undermine complex trusted interface that provides access to native another’s decision to favor security. Of course, requiring libraries [8, 10, 17, 20]. This complexity undermines the each app vendor to implement a complete software stack intent to provide strong security. is impractical, so we expect this complexity to migrate to While native code is a target that every compiler can app frameworks that app vendors can choose among, just hit, it seems daunting to port arbitrary POSIX apps to as web developers choose among an ever evolving set of such a minimal interface. Such apps expect to run on a app frameworks on the server. complex host with hundreds of system calls and dozens The minimality of the client interface must not inhibit of system services, reflecting decades of development. the richness required by applications such as desktop However, our experience suggests this task is far eas- productivity apps. New client application models often ier than one might expect. Interactive apps use relatively fail due to the burden of migrating every app–and ev- little of the complexity available in modern host plat- ery library–to run under a new model. Thus, we argue forms. More importantly, rather than alter the app, the that shifting app delivery to a minimal-client model re- functions that are required can often be emulated behind quires an inexpensive app migration path from complex- the POSIX interface. This technique works without even host frameworks such as POSIX and Windows. recompiling the hundreds of libraries involved. The em- On the other hand, support for richness should not sac- ulation work can be shared easily across many applica- rifice the small size and tight specification of the isolation tions, making the porting work scalable. The broad se- interface. The web’s current client execution interface lection of rich apps that our system supports (see Table 1) has repeatedly failed to achieve strong app isolation, due demonstrates the generality of the approach. to an interface bloated with HTML, DOM, JPG, PNG, Contributions. This paper demonstrates the tractability JavaScript, Flash, etc. in pursuit of richness. of porting rich POSIX apps to a minimal environment, The recent Embassies system provides a concrete ex- thus enabling them to run on a multitude of minimal ample of how to achieve both security and richness si- client hosts [13, 16, 18, 22, 31]. We give a full account- USENIX Association 2013 USENIX Annual Technical Conference (USENIX ATC ’13) 321 ing of the porting task, including which functionality is specific secret. Apps use this key, along with cryp- required and where corners can be cut. This includes tographic libraries, to store and recover private in- low-level details, such as an exhaustive list of syscalls formation despite starting from a public binary. handled, to enable reproducibility and to eliminate any Communication. All communication outside the pro- ambiguity about complexity hidden under the hood. Ul- cess, whether IPC to another process on the local ma- timately, we hope that this will expedite other efforts to chine, or remote to an Internet host, follows IP seman- adopt these techniques and hence achieve rich applica- tics: Data is transferred by value (a logical copy), so tions atop minimal, strongly-isolating client kernels. that the suspicious recipient needn’t worry about concur- rent modification; addressing is non-authoritative; deliv- 2 Background: Minimal Client Facilities ery admits loss and duplication; packet privacy and in- In this work, we aim to transplant apps from a rich tegrity are not guaranteed. Just like servers on the Inter- POSIX interface to a minimal client kernel. To ground net, apps build up integrity and privacy themselves using the discussion, we target the minimal Embassies pico- cryptography. To underscore these semantics, all com- process interface [16], since it takes minimality to an munication in Embassies–remote or local–is done via IP. extreme. If we can port an app to Embassies, we can • get addresses assigns the process one IPv4 certainly port it to a client with a richer interface. and one IPv6 address. The Embassies application binary interface (ABI) pro- • allocate packet allocates memory for an out- vides execution primitives that support an app’s internal going packet; this allocation is distinguished from computation, cryptographic primitives to facilitate pri- allocate memory to enable zero-copy transfer. vacy and integrity, primitives for IPC and network com- • send packet delivers a packet, interpreting its munication, and user interface (UI) primitives for user argument as an IP header and payload. interaction. • receive packet returns an allocated and de- Execution. The execution primitives include: queued packet, or NULL if the queue is empty. • Calls to allocate memory and free memory. • free packet frees an allocated packet. To simplify the specification and to make the ABI User Interface. portable to most host environments, the app speci- • ui event returns a dequeued UI event (keystroke fies only the amount of memory required; it has no or pointer motion), or NULL if the queue is empty. control over the addresses returned by the allocator. • Some calls that manage viewports, letting them be • create thread accepts only the thread’s initial transferred among applications, or letting one ap- program counter and stack pointer; the application plication sublet a region of its viewport to another provides the stack and any execution context. application. In every case, even where nested, each • exit thread destroys the current thread. viewport is owned by a single app; no app can in- • A simplified futex-like [6] synchronization schedul- spect or modify the pixels of another app’s view- ing primitive, the zutex. zutex wake is a race- port. Details can be found elsewhere [16]. free scheduling primitive that supports app-level ef- • map canvas allocates a framebuffer to back a ficient synchronization primitives. The correspond- viewport. This allocation is distinguished from ing zutex wait is the only blocking call in the allocate memory to enable fast pixel blitting. ABI; it allows an app to yield the processor. • update canvas informs the client kernel that a • clock returns a rough notion of wall-clock time. region of the framebuffer has been updated, and that • set timer sets a timer, in clock coordinates, that its pixels should be blitted to the display. wakes a zutex on its expiration. Each picoprocess These calls comprise the entire Embassies ABI; all of has only one timer; the app must multiplex it. the functionality described in the rest of the paper is im- • get alarms returns a list of three distin- plemented in terms of these primitives. guished zutexes representing external events, one for each of receive packet, ui event, and 3 The POSIX Emulator timer expired. Waiting on these zutexes is how A conventional POSIX application employs dozens of threads block on external activity. libraries, access to a rich system call interface, and by • A call to create a new picoprocess. way of those system calls, access to other rich services, such as the X server’s graphics functions and the dbus Cryptographic Infrastructure. desktop configuration object broker. • random provides a supply of cryptographically To execute applications expecting this rich POSIX en- strong entropy. vironment, our POSIX emulator cleverly repurposes ex- • app key provides a machine-specific, application- isting libraries and programs atop the execution environ- 2 322 2013 USENIX Annual Technical Conference (USENIX ATC ’13) USENIX Association stack allocations heap allocations gimp ..