Sistemas operativos modernos

Java no tiene variables de apuntador, conversión explícita {cast), asignación de almacenamien­ to controlada por el usuario (como malloc y free), y todas las referencias a arreglos se verifi­ can en fiempo de ejecución. Los programas en Java se compilan hacia un código binario intermedio llamado código de bytes de máquina virtual de Java (JVM). JVM fiene cerca de 100 instrucciones, casi todas las cuales meten objetos de un tipo específico en la pila, los sacan de la pila, o combinan arit- méficamente dos objetos en la pila. Estos programas en JVM por lo regular se interpretan, aun­ que en algunos casos pueden compilarse a lenguaje de máquina para acelerar su ejecución. En el modelo Java, los applets enviados por Internet para ejecución remota son programas JVM. Cuando llega un applet, se pasa por un verificador de código de bytes JVM que prueba si obedece ciertas reglas. Un applet debidamente compilado las obedecerá en forma automática, pero nada impide a un usuario mal intencionado escribir un applet JVM en lenguaje ensambla­ dor de JVM. Las verificaciones incluyen: 1. ¿El applet intenta falsificar apuntadores? 2. ¿Viola las restricciones de acceso de miembros de clases privadas? 3. ¿Trata de usar una variable de un tipo como si fuera de otro? 4. ¿Genera desbordamientos o agotamiento de la pila? 5. ¿Convierte de forma prohibida variables de un fipo a otro? Si el applet supera todas las pruebas, puede ejecutarse sin temor de que entre a memoria que no sea la suya. Sin embargo, los applets sí pueden hacer llamadas al sistema invocando métodos (proce­ dimientos) Java suministrados con ese fin. La forma en que Java maneja eso ha evolucionado al paso del tiempo. En la primera versión de Java, JDK {Java Development Kit) 1.0, los ap­ plets se dividían en dos clases: confiables y no confiables. Los applets extraídos del disco lo­ cal eran confiables y se les permitía hacer todas las llamadas al sistema que quisieran. En contraste, los applets obtenidos en Internet no eran confiables; se ejecutaban en una caja de are­ na, como se muestra en la figura 9-19, y casi no se les permitía hacer nada. Después de cierta experiencia con este modelo, Sun decidió que era demasiado restrictivo. En JDK 1.1 se emplearon firmas de código. Cuando un applet llegaba por Internet, se verificaba si había sido firmado por una persona u organización en la que el usuario confiaba (definida por la lista de firmantes de confianza del usuario). En tal caso, se permitía al applet hacer lo que quisiera. Si no, se ejecutaba en una caja de arena y se restringía en forma rigurosa. Después de más experiencia, esto tampoco resultó satisfactorio, así que se modificó otra vez el modelo de seguridad. JDK 1.2 ofrece una política de seguridad de grano fino configura­ ble que se aplica a todos los applets, tanto locales como remotos. El modelo de seguridad es lo bastante complejo como para escribir un libro entero (Gong, 1999), así que sólo resumiremos en forma breve algunos puntos destacados.