Sistemas que descargan c´odigo en el µ kernel

El primer enfoque permite adaptar el sistema s´olo en el modo en que se haya previsto en tiempo de su dise˜no [18, 17]. La descarga de c´odigo de aplicaci´on dentro del Sistema Operativo s´olo puede efectuarse con ´exito all´ıdonde no interfiera con los servicios queya est´asuministrando el SO. Lo que es m´as, las t´ecnicas existentes para asegurar la confiabilidad del c´odigo introducido no est´an a´un bien desarrolladas y presentan serios inconvenientes [148].

Ser´ıa factible modificar este tipo de sistemas para incorporar el modelo de sistema que propo- nemos. Dado que en ellos tan s´olo es posible modificar aquellas componentes del SO para las que el arquitecto del mismo ha permitido la descarga de c´odigo de usuario, la incorporaci´on del modelo de DAMN requerir´ıa importantes cambios en la implementaci´on de estos sistemas. Alternativamen- te, podr´ıa modificarse la asignaci´on/revocaci´on de recursos f´ısicos (realizada dentro delµkernel en

´estos sistemas) para que el c´odigo de aplicaci´on tuviese acceso a dichos recursos y los nombres y protecciones empleados tuviesen validez en la red.

Spin

Spin [17] permite a las aplicaciones adaptar el funcionamiento del sistema mediante el uso despin- dles, fragmentos de c´odigo escritos en un lenguaje con tipado estricto de datos. La idea de partida radica en que para cada pol´ıtica empleada dentro delµkernel es posible establecer unspindlecomo implementador de la misma. Permitiendo a las aplicaciones el establecimiento de spindles dentro del

µkernel es factible entonces que ´estas puedan emplear sus propias pol´ıticas.

El problema de este enfoque radica en que las partes del sistema que es posible adaptar est´an prefijadas de antemano. S´olo es posible adaptar el funcionamiento de aquellos elementos del sistema que el arquitecto del mismo ha dispuesto comospindles. Los sistemas que adoptan un esquema de especializaci´on din´amica de c´odigo (ver apartado 4.4.3) presentan problemas similares.

Cuando una aplicaci´on ejecuta una llamada al sistema se instalan sus spindles de tal modo que, por ejemplo, un fallo de p´agina, una operaci´on bloqueante de E/S, etc. den lugar a la ejecuci´on del spindle injertado por la aplicaci´on en el µkernel. En realidad, se emplea un esquema de despacho din´amico6_{para escoger la implementaci´on deseada. ´Este trabaja conjuntamente con t´ecnicas de co-}

ubicaci´on (carga din´amica de c´odigo en elµkernel) para permitir la inserci´on de spindles en tiempo de ejecuci´on. El despacho din´amico introduce algo de sobrecarga en la ejecuci´on de todas y cada una de las llamadas al sistema, aunque esta sobrecarga es m´ınima.

La descarga de c´odigo de aplicaci´on dentro delµkernel introduce adem´as problemas de seguri- dad en el sistema. Elµkernel no puedeconfiaren el c´odigo de aplicaci´on, por lo que se requiere de t´ecnicas orientadas a garantizar la seguridad del c´odigo que las aplicaciones introducen en elµkernel. As´ıse fuerza el uso de un compilador (en el que el sistema ha de confiar, con los consiguientes pro- blemas de seguridad que ello supone) con tipado estricto de datos y modularidad; Spin usa Modula 3 [57]). Se introduce as´ımismo el uso de dominios de protecci´on l´ogicos consistentes en espacios de nombres empleados por elµkernel de tal modo que las extensiones efectuadas por las aplicaciones tengan acotado el conjunto de recursos delµkernel que pueden referenciar.

El sistema Spin es un sistema centralizado, por lo que no trata de abordar la combinaci´on de adaptabilidad y distribuci´on del sistema. En principio ser´ıa factible emplear la t´ecnica de descarga de c´odigo dentro delµkernel, como hace Spin, para adaptar el funcionamiento de un sistema distribuido, aunque incurrir´ıamos de nuevo en el problema mencionado anteriormente.

Vino

Vino [149] adopta un enfoque similar al de Spin, dado que permite insertar c´odigo (grafts o injer- tos en Vino) en el kernel como mecanismo b´asico de adaptaci´on del sistema. Consiguientemente presenta los problemas (mencionados en el apartado anterior) derivados de esta estrategia. Vino se plantea extensiones que alteren la pol´ıtica, el rendimiento y la funcionalidad del sistema aunque no es factible reemplazar aquellas abstracciones que resulten inadecuadas y ya est´en presentes en el sistema.

Vino suministra un interfaz com´un que se emplea para cualquier recurso presente en el sistema. Dicho interfaz es independiente de la representaci´on adoptada por cada recurso. Los recursos en Vino son entidades que poseen un conjunto de operaciones y un conjunto de propiedades (algo no muy diferente de la estructura de los recursos en sistemas basados en objetos). En cuanto al nivel de abstracci´on de dichos recursos, debemos decir que ´estos incluyen abstracciones tales comoficheros.

Estos recursos est´an tipados y, aunque pueden reemplazarse (o su implementaci´on extenderse) en tiempo de ejecuci´on, la jerarqu´ıa de tipos de dichos recursos en Vino ha de indicarsepor completoen tiempo de compilaci´on del sistema. Sorprendentemente, esta limitaci´on es expl´ıcitamente introduci- da por los autores del sistema [149] de tal modo que se beneficie el rendimiento y la robustez como consecuencia de la informaci´on adicional (tipos) suministrada. Como compensaci´on, se permite in- troducir nuevossubtiposen tiempo de ejecuci´on (un subtipo ha de mantener al menos la sem´antica del tipo de que deriva).

Pensando ahora en la implementaci´on de los recursos, y no en el interfaz que ´estos presentan, la implementaci´on por defecto que suministra el sistema para los distintos recursos puede alterarse mediante la introducci´on degraftsen el n´ucleo del mismo. Como vemos, Vino resulta entonces muy similar a Spin. Al contrario que Spin, Vino emplea C y C++ como lenguaje para escribir grafts. El compilador que se emplea para compilarlos introduce comprobaciones adicionales en todos los accesos a memoria y en todas las llamadas a funci´on. En nuestra opini´on, resulta en este caso m´as efectivo el empleo de un lenguaje con tipado estricto de datos como Modula 3, de tal modo que gran parte de estas comprobaciones puedan obviarse, aunque es cierto que sin dichas comprobaciones un usuario malicioso puede emplear un compilador modificado7 _{para sortear el sistema de tipado}

estricto.

Una de las contribuciones de los autores de Vino es la clasificaci´on de los distintos modelos de extensiones que pueden realizarse [148]. Dichos autores distinguen entre extensiones de priorizaci´on, de streaming y de caja negra. El primer modelo se basa en asignar prioridades a distintos elementos de entre los que se supone hay que escoger alguno(s). Un caso t´ıpico es la elecci´on de una p´agina a reemplazar. As´ı, anidando distintas pol´ıticas es factible partir de un conjunto original de elementos e ir aplicando dichas pol´ıticas de forma sucesiva hasta obtener el conjunto final de elementos que interesa. El segundo modelo, streaming, se basa en el procesamiento mediante pipe-lines de tal modo que sucesivos componentes vanfiltrando los datos de que se parte hasta obtener un conjunto de datos ya procesado. El tercer modelo (caja negra) es el m´as general y consiste en un elemento software que tiene algunas entradas, un proceso que no conocemos (y sobre el que no cabe hacer suposiciones) y presenta una ´unica salida. La pol´ıtica de “read-ahead” en un disco es un ejemplo de este ´ultimo modelo.