Temas sugeridos a desarrollar para exposición

Complementando a la división de espacio usuario y espacio kernel, podemos preguntarnos acerca de cómo se puede burlar los mecanismos seguridad.

Si bien a estas alturas del curso aún no hemos profundizado en muchos de estos temas (e incluso este tema podríamos presentarlo durante unidades posteriores), podemos comenzar a hablar de las amenazas: Una vez que un atacante logró romper a un programa al que tenía acceso, engañando al sistema operativo para que le dé acceso privilegiado, buscará para esconder sus rastros del administrador y, además, asegurarse de tener un mecanismo fácil para entrar posteriormente.

¿Cómo lo hace? ¿Cómo se puede detectar?

El modelo de cómputo distribuído basado en una malla o grid es muy flexible, y lo han adoptado proyectos de todo tipo. Pueden presentar a algunos de estos proyectos: ¿Qué es lo que se distribuye? ¿Cómo se paquetiza la información? ¿Cómo se re-agrega? ¿Qué tanto costo computacional adicional significa el separar en estos paquetes a la información?

Se puede emplear un modelo grid con participantes conocidos, con una membresía predeterminada, pero muchos proyectos lo abren a participación pública. ¿Hay consideraciones de seguridad a tomar en cuenta?

Tras muchos años (¿décadas?) de encontrar gran resistencia por parte de la industria, al día de hoy buena parte de las computadoras nuevas vienen con el módulo de plataforma confiable (Trusted Platform Module) activo. Este polémico módulo implementa verificación de la integridad del sistema operativo, evitando que un ataque (sea un virus o un agente hostil) ejecute código que altere la operación del sistema operativo o incluso ejecute antes de éste y lo envuelva (por ejemplo, en un esquema de virtualización).

TPM, sin embargo, también evita que el dueño de una computadora la use como él quiera, teniendo que ejecutar únicamente los sistemas operativos aprobados o firmados por el fabricante.

Hay mucho que se puede decir acerca de TPM. ¿Cuál es tu planteamiento?

Sugiero como lectura para preparar este trabajo los varios artículos en el blog del desarrollador Matthew Garrett, particularmente entre septiembre del 2011 y mayo del 2013. Garrett lidereó la alternativa que al día de hoy más se usa para poder iniciar Linux en un sistema bajo TPM; tiene decenas de artículos desde muy descriptivos y generales hasta técnicos y específicos a puntitos particulares. Hay otro artículo interesante al respecto, de Jonathan Corbet (septiembre 2013): BSD-style securelevel comes to Linux — Again. Este artículo es de acceso restringido a subscriptores de LWN, pero si les interesa desarrollar el tema, les doy una copia. Explica con bastante detalle cómo es que se plantea implementar el nivel de protección que busca ofrecer TPM desde un sistema Linux.

Al hablar de virtualización, sea asistida por hardware o paravirtualización, varias voces se han levantado, indicando que ejecutar un sistema operativo completo dentro de una máquina virtual es un desperdicio de recursos. A fin de cuentas, si el sistema operativo típico a correr dentro de una máquina virtual en el CP del S/360 de IBM, hace más de 40 años, era un sistema sencillo, interactivo y monousuario (CMS), ¿por qué no repetir la experiencia?

Un ejemplo de sistema mínimo fue presentado en septiembre de 2013: OSv. Busca no implementar los subsistemas innecesarios de un Linux tradicional, pero permitir la ejecución de varios de los procesos más comunes en una máquina virtual. Pueden buscar al respecto:

• Anuncio en Slashdot: /New operating system seeks to replace Linux in the cloud
• Presentación del proyecto, del congreso CloudOpen
• Artículo respecto al lanzamiento de OSv en The Register
• Depósito Git del código de OSv en GitHub

Algunos puntos que podrían desarrollar:

• ¿Qué gana OSv y otros proyectos por el estilo? ¿Qué pierden?
• ¿Cómo ha avanzado la adopción de estas ideas?
• ¿Qué le agrega o quita a la complejidad de la administración de sistemas?
• ¿Qué significa esto para nuestra carrera/futuro profesional? ¿Hay de nuevo espacio para desarrollar sistemas operativos novedosos, o serán unos pocos los que llenarán el nicho?

Lo exponen: Arturo López y José Espinosa, jueves 5 de septiembre

Edgser Dijkstra, además de desarrollar los semáforos como herramienta de sincronización, desarrolló también un arlgoritmo que no requiere basarse en primitivas — Que puede ser implementado completamente entre dos o más hilos o procesos, sin requerir de la mediación de un agente de nivel superior (como puede ser el sistema operativo), basado en la comunicación a través de memoria compartida, únicamente al costo de hacer espera activa.

Lo expone: Lisette Castro, jueves 12 de septiembre

Un tema no directamente relacionado con el temario, pero que puede ligarse con varios conceptos mencionados en esta unidad, es la gestión del arranque del sistema: Una vez que el núcleo carga y hace un recorrido básico del hardware creándose un mapa de cómo es el sistema en que está corriendo, tiene que llevar el equipo a un estado funcional para sus usuarios. ¿Cómo ocurre esto?

Tradicionalmente, los sistemas Unix se dividían entre dos filosofías de arranque (los sistemas SysV y los sistemas BSD). Pero la realidad del cómputo ha cambiado con el tiempo. Si bien hay varias otras propuestas, en el mundo Linux hay dos apuestas primarias: upstart, por parte de Ubuntu, y systemd, por parte de las distribuciones derivadas de RedHat.

¿Cuáles son los planteamientos básicos de los arranques tipo SysV y tipo BSD? ¿A qué tipo de cambios en la realidad me refiero? ¿Por qué los esquemas tradicionales se están quedando cortos? ¿En qué se parecen y en qué se diferencian systemd y upstart? ¿Qué ventajas y desventajas conllevan?

Esta unidad es en la que más nos dedicaremos a escribir y analizar código. Si bien para presentar como casos de ejemplo presentamos a cuatro de los casos clásicos (el problema productor-consumidor, el problema lectores-escritores, la cena de los filósofos y los fumadores compulsivos), hay muchos otros casos ampliamente analizados.

Pueden presentar otro de los casos presentados en el libro recomendado como referencia, The little book of semaphores (Allan Downey, 2008), o de alguna otra fuente.

En su libro Sistemas operativos: diseño e implementación, Andrew Tannenbaum sugiere otro esquema de planificación: El de la lotería.

En este esquema, cada proceso tiene un cierto número de boletos, y sl siguiente quantum es asignado a través de la selección aleatoria de uno de los boletos disponibles. Un proceso de mayor prioridad tendrá más boletos, uno de menor prioridad tendrá menos.

• ¿Cómo se compararía este método con los otros revisados en clase?
• ¿Para qué tipo de carga es más apto? ¿Y menos apto?
• ¿Qué tan susceptible resulta a producir inanición?
• ¿Qué tan justa sería su ejecución?
• ¿Cómo lo emplearías si tuvieras procesos con necesidades de tiempo real?
• ¿Se te ocurre algún punto adicional no mencionado en el planteamiento para que resulte mejor?

Los sistemas operativos modernos buscan exprimir hasta el último pedacito de rendimiento. Para estudiar cómo lo hacen, podemos asomarnos a las discusiones (y a la implementación) de Linux. Los últimos diez años han sido de fuerte profesionalización y optimización.

Para el tema de planificación de procesos, un punto muy importante fue la introducción del kernel prevenible (o interrumpible), en 2004.

¿Qué significa que el núcleo mismo del sistema operativo puede ser interrumpido? ¿Quién lo puede interrumpir? ¿Qué consecuencias tuvo esto, en complejidad de código y en velocidad?

En agosto del 2013, Linux Weekly News publicó un texto llamado Optimizing preemption, de Jonathan Corbet. Les sugiero revisarlo y tomarlo como punto de origen para el desarrollo del trabajo. Si bien este tema toca principalmente temas de planificación de procesos, si eligen este tema les sugiero adelantarse un poco leyendo la sección de El espacio en memoria de un proceso (y posiblemente, para una mayor comprensión, Consideraciones de seguridad) del tema de la siguiente unidad, Administración de memoria.

La realidad que presentamos en la primer unidad del curso respecto al multiprocesamiento simétrico como fuertemente dominante en relación a los sistemas NUMA se mantiene cierta… Pero va cambiando rápidamente, y los sistemas NUMA son cada vez más comunes.

Claro está, la popularización de los sistemas NUMA tiene un alto impacto en cómo se manejan los esquemas de administración de memoria.

En el número de septiembre del 2013 de la revista Communications of the ACM aparece un artículo corto, conciso y bastante interesante, de Cristoph Lameter: An overview of non-uniform memory access. Sugiero emplearlo como punto de partida.

En clase exponemos los principales puntos de los medios de estado sólido o no rotativos, apuntando apenas hacia cómo podrían estos aprovecharse mejor.

¿Qué sistemas de archivos están mejor afinados para operar con medios Flash? ¿Cuáles son los principales obstáculos para que gocen de una mayor adopción?

Una de las características que ofrecen varios sistemas operativos de última generación es la desduplicación: La detección de sectores idénticos pertenecientes a más de un archivo, para evitar repetirlos varias veces en el disco (es un fenómeno que ocurre mucho más de lo que esperaríamos). Esta detección se realiza típicamente por medio de hashes criptográficos.

¿Cómo opera un poco más a detalle este mecanismo? ¿Qué tan confiable es? (vamos, ¿se puede utilizar ya en sistemas en producción?) ¿Qué pasa con el espacio libre reportado al sistema? ¿No se cae en riesgos de sobrecomprometimiento (overcommit)? ¿Qué es la desduplicación en línea y la desduplicación fuera de línea (online deduplication, offline deduplication)? ¿Cómo opera el hash criptográfico? ¿Hay veces que resulte insuficiente? ¿Qué alternativas hay?

Como referencia informal al respecto, sugiero leer el hilo de discusión al respecto en la lista de DebConf (el congreso de Debian).