Spin Leading OS Research Astray?

Transcription

1 Advanced Tpics in Cmputer Systems, CS262B Prf Eric A. Brewer Spin Leading OS Research Astray? January 27, 2004 I. Extensibility, Safety and Perfrmance in the SPIN Operating System Gal: extensible OS that has bth safety and gd crss-dmain perfrmance Why build an extensible OS? Perfrmance: a general-purpse OS handles all apps equally prly. E.g, multimedia apps, passing buffers between netwrk and disk, new netwrk prtcls,... 3rd-party develpment: untrusted third-parties can write extensins withut need kernel surce cde, and withut cmprmising the safety/security f the kernel. In turn, this shuld speed up innvatin. risk management: faster and safer t develp extensins, rather than kernel mds. change is the nrm! better t make a changeable system rather than a mnlithic ne Nte that these gals apply t plug-ins, applets, and Active X as well. In all cases, we enable innvatin and third-party develpment that ideally shuld be safe relative t the base system. Databases have similar extensin mechanisms (ften called blades ). Hw t extend: insert trusted cde int the kernel dynamically -- key claim: this is necessary fr perfrmance reasns (wins by aviding kernel crssings) Use a type-safe language (Mdula 3) t enfrce namespaces securely. I.e., extensin run in the kernel address space, but can t muck with anything that they can t explicitly name. They call this enfrced mdularity. Type-safe => n dangling references => must have autmatic strage management (garbage cllectin) Als need dynamic linking, since we dn t want t rebt fr every new extensin Spin has basic mdules fr VM and scheduling, and uses events t interact with extensins Alternative framewrks have different answers: applets are safe and use dynamic linking, Active X is dynamic but nt safe (but is authenticated); plug-ins are neither safe nr dynamic, same with database blades. 1

2 Signed mdules: Mdula-3 des nt have a byte-cde verifier => mdules must be signed by the cmpiler Hw des the cmpiler have a secret key? this is unclear, but it can t just be in the executable, since an attacker culd steal it. slutin 1: cmpile everything lcally, s that the key is nly valid fr the lcal machine (and hence damage due t a stlen key is limited t the lcal machine as well). Stealing the key shuld be just as hard as getting rt access, and thus intrduces little additinal weakness. Java kind f des this by verifying everything lcally; the cmpiler utput is nt actually trusted. slutin 2: have a cmpiler service that is shared. Stealing its key wuld allw a bad mdule t exist in many places, but the centralizatin makes it pssible t secure the key well. (this is like verisign fr certificates) The bad case ccurs when yu lad mdules signed by cmpilers frm ther machines; can yu trust that machine has nt been cmprmised? Bundaries: althugh nt in this paper, Spin makes a gd venue t talk abut bundaries. By bundary, I mean tw sides f an API that have different trust levels. Extensin bundaries and kernel crssing are examples f bundaries, as are plug-ins and applets. In each case, there is the base side that is trusted, and the extensin side that is nt (at least nt as much). In this sectin, I utline all f the issues that yu have t think abut whenever yu have a bundary; there is a huge number f them and they are rarely explicit r even discussed. Spin cvers mst f them well, but never views the issues all tgether as the set f bundary prblems. Shared prtectin dmain: are the tw sides in the same prtectin dmain? If nt, there is less trust needed. Spin uses a shared address space but depends n Mdula-3 t limit access. Nemesis is an unusual case in that it has ne address space, but separate dmains. Plug-ins are same address space and are trusted but nt always trustwrthy. Shared strage: even when using separate dmains, there may be shared memry regins r shared strage. These regins can clearly be damaged by an extensin. The usual answer t this is t have the base system check the shared regins befre use. A simple example is argument checking fr kernel calls. Similarly, shared files can be checked fr validity befre being used by the base system. Are there pass by reference arguments acrss the bundary? If s, there is clearly shared strage. It is literally shared (extensin updates are immediately visible in the base), r it is really pass-by-cpy-result (pass by value, then cpy the result back). LRPC is cnfused abut this issue. There are tw directins t wrry abut: 1) the extensin passes in a reference -- can it then change the value while the base is using it? 2) the base passes a reference t the extensin -- des the extensin have read/write r readnly access t the base value? There is anther mre subtle issue in the Spin case: if we pass a pinter ut t an extensin, it might pass it back in with a different type, thus defeating the type safety. Spin avids this by externalizing the reference, which basically means make a table f pinters and pass ut the index rather than the pinter. The extensin can pass back in the reference (integer), but the table securely stres the real type. What is the lifetime f a reference passed acrss the bundary? This is a tricky ne 2

3 that is almst always left ut. The default answer is that a reference is gd frever and the base cannt mve, r really even use, the shared bject. (The base culd lck the bject, but these is really n reasn t think the extensin will fllw the lcking discipline.) The tw simplest slutins are t either avid pass by reference (nly pass values), r t have references expire (leases). With expiratin, there needs t be a way t detect the use f expired references, which implies a level f indirectin -- yu can t use pinters directly, nr can yu pass in the timestamp, unless it was signed by the base. In thery, ne culd garbage cllect references acrss a bundary, but requires nt nly a shared GC system, but that the extensin can t pass references utside the GC bundary (such as string them in a file r giving them t a nn-gc system). Faults brake the GC mdel as well: if an extensin becmes discnnected when d yu GC references it had? T summarize, unless yu re within ne prtectin dmain, GC prbably desn t make sense, leases wrk OK, and pass by value is the simplest. The prblem with leases is that it is hard t build systems that wrk rbustly when leases expire during crrect use. Partial failure: can the ther side fail withut this side failing? If s all crssings have nn-transparent exceptinal cnditins, and all crssing prbably need a timeut. If an extensin fails, can yu just restart it? Hw des the base clean-up the state f the lst upcalls? LRPC cvers these cases pretty well, RMI less s. Are there shared threads? I.e. des a thread crss the bundary r is there sme kind f handff? RMI and LRPC clearly have a handff and thus use separate threads. Extensins share threads; Spin kernel crssings d nt share threads. Can an extensin swallw a thread and never return it? This is usually the fear that drives fr separate threads an each side. Evlutin: can the tw sides evlve independently? Fr lng-lived systems this is a prerequisite that is nrmally ignred. It is usually easy t evlve the extensin, but hw d yu evlve the base withut breaking all f the extensins? Mac OS has prbably dne the best at this. One answer is t never evlve a particular interface -- make interfaces immutable and add new interfaces t evlve the system. The ld nes are left just t supprt legacy extensins. Wh decides that a new versin f the base is backward cmpatible (and what if they re wrng)? Fr big upgrades, it is cmmn t frce evlutin f all f the extensins (e.g. fr Windws 2000, mst drivers must be updated, at least thse frm Windws 95/98). Micrsft COM has unique IDs fr every interface s that an evlved interface is clearly marked as different; cnversely, if yu get the same ID, then yu knw yu have the same interface (but nt necessarily the same implementatin!) Admissin cntrl: is there a limit n crssings, r n cncurrent crssings? RMI has this prblem in spades -- every new call typically spawns a new thread and runs cncurrently, eating up resurces until the system falls dwn. Is the admissin cntrl general r per-client? In general, the way t slve this is with explicit queues fr incming crssings; excess crssings can be drpped r failed immediately. A cunt f utstanding calls may als wrk, as lng as it desn t leak (which seems t be surprisingly hard in practice). Fr synchrnus interface, the number f threads limits the number f crssings, but fr async the limit must be enfrced sme ther way. Resurce allcatin: hw d extensins get resurces and hw are their resurce limits defined? This cmes up in netwrk/disk buffers, physical memry (ACPM has a nice slutin), and sckets amng thers. In general, it is hard fr a server t crrectly accunt fr the resurce usage f its clients (n a per-client basis). Hard cases including 3

4 shared verhead in the VM r interrupt system fr example. Can yu uninstall an extensin? Ideally, installing an extensin wuld be transactinal, and if yu abrted it, everything wuld return t nrmal. I dn t really knw f any systems that achieve this, but DLLs clearly d nt. What if applicatins are using the extensin? Typically wuld yu stp new apps frm using it, and then wait fr the current nes t stp. Files systems have t d this fr deleted files. upcall summary: use pass-by-value, r externalized references. It is useful t have timeuts fr calls, and expiratins fr references passed ut. Externalized references are really paque tkens that have n use t the extensin except as smething t pass back later. dwncall summary: decide if it is sync r async; check args n the way dwn; dn t accept true pass by reference (but pass by value-result is OK, since there is n shared regin). It is useful t enable app-specific clsures t be passed in. These are tkens that are paque t the base, but allw the applicatin t have cntext when a result is returned, and thus simplifies reply matching fr the asynchrnus case. In Spin, there are tw kinds f bundaries: extensin bundaries and the user-level bundary. The latter is a fairly typical kernel crssing with arg checking. Externalized references fr the user-level bundary, while type-safety is fr the extensin bundary. Nte that references are OK acrss the extensin bundary because there is a shared GC system (as well as shared memry and address space). Extensins shares threads, but threads never crss the user-level bundary -- during a blcking call there are tw threads invlved, ne fr user level (which blcks) and ne fr the kernel. Unix Interface: Mstly written in C n tp f C-Threads implementatin f the Strand interface Small Mdula-3 cre underneath the Unix C cde Similar t Exkernel LibOS cncept Capabilities: just type-safe pinters! enfrced mstly at cmpile time (e.g. except fr array bunds checks) externalize these pinters if yu need t give them t untrusted cde, just file descriptrs in Unix (an array f pinters and yu pass ut the index). Dmains: Just f set f (name, bject) bindings used fr dynamic linking Reslve lks up unreslved symbls in target against exprted symbls in surce Use tw reslves t crss-link dmains Linked dmains are in the same address space: the new links are new capabilities Can further restrict these links with run-time checks Event dispatch: the default case is ne handler fr each surce f events 4

5 But may have many handlers fr an event -- need t rder them and cmbine them Generates cmbinatin cde dynamically as handlers are added Each handler may have a guard, s that it nly applies in sme situatins -- this is the way t demultiplex events (e.g. netwrk prtcl dispatch) Als need t figure ut return value fr an event, which is nt clear since it may cause many callees t execute. Default plicy is the return value f the last handler executed, but the rder is undefined (!). II. Extensible Kernels are Leading OS Research Astray Claims made by extensible OS researchers: safely achieve high perfrmance fr wide range f apps rapidly deply OS innvatins cntain/manage increasing OS cmplexity Cunterclaim: nly the first ne has been addressed, and cmplexity is in fact much wrse Basic prblems: dn t need general-purpse extensibility -- best ideas can just be added t a regular OS withut the need fr new mechanisms fr safety easily mdified bundaries are nt a gd idea lng term: hinders cmpatibility, interperability, and the ability t evlve... (must yu supprt everything that was extended in the past?) safe extensins intrduce new cmplex prblems that are hard t slve (witness XN disk blck scheme, trusted cmpilers, etc.) Alternatives are OK: simple little language extensins (packet filters) existing techniques: ACPM, scheduler activatins, U-Net are all safe and much simpler Example: web server TCP implementatin: just fix it directly (dne nw) TCP prtcl ptimizatin: better interface is sufficient frking/switching: better threads (Capricci) filesystem: several slutins, including specialized file systems fr web caches VM/cache cntrl: better interface is sufficient cpying verhead: U-net r IO-Lite duble buffering: ACPM TCP checksum calculatin: netwrk layer can cache checksums itself (mre reliable) 5