sistemas

sistemas

Introducción

Una de las etapas de la evolución de los sistemas operativos fue la multiprogramación o multitarea, esto que trajo consigo que se tuviera en cuenta ungrupo de consideraciones a la hora de concebir los mismos. Así fueron surgiendo distintas estructuras en el diseño, cada una con sus características particulares.

Protección

En los primeros sistemas de cómputo que se utilizaron no fue necesario tener en cuenta la problemática de la protección debido a la forma en que se operaban, es decir se ejecutaba sólo un programa y éste estaba en posesión de todos los recursos existentes (en caso de error, solo se afectaba él).

Al desarrollarse los sistemas operativos aún cuando se mantuviera un único programa en memoria (monoprogramación), se comenzaba a compartir recursos. En este caso, el programa y el sistema operativo comparten la memoria. Si ocurriera un funcionamiento erróneo del programa y él sobrescribe el área de memoria del sistema operativo, resulta evidente que existirá un "crash" de éste.

Otro ejemplo simple se puede notar en el caso del procesamiento en lote. Suponga que un programa cae en un lazo infinito de lectura de tarjetas. Es evidente que tomará todas las que les pertenecían y las que le siguen.

El compartir recursos aumenta la utilización eficiente de estos, pero a la vez incrementa las dificultades. Un error en un programa puede afectar a otros trabajos.

En los sistemas operativos que instrumentan la multiprogramación, pueden ocurrir muchas otras situaciones no tan evidentes como las indicadas, por esto éste se debe proteger y a la vez brindar protección a todos los programas que se ejecutan. Todo recurso compartido debe ser protegido, pero al menos deben disponer de esta característica las entradas y salidas, la memoria y la CPU.

La protección de entrada–salida se logra al no permitir que los programas actúen directamente sobre los dispositivos, sino a través de llamadas a los manejadores de dispositivos que forman parte del sistema de operación. De esta forma se puede chequear si la solicitud es correcta o no y evitar que algo vaya mal.

Para evitar que un programa opere directamente con la entrada–salida, las instrucciones correspondientes se declaran como privilegiadas (esto tiene que estar instrumentado en el hardware) y por ello sólo podrán ser utilizadas por parte del sistema operativo.

Lo antes indicado quiere decir que el hardware deberá brindar dualidad en el modo en que los programas se ejecutan. El primero es el modo "kernel" (omonitor, supervisor, sistema, protegido), y el segundo es el modo usuario. El SO correrá en modo protegido (con derecho a usar instrucciones privilegiadas) y todos los demás en modo usuario.

Por supuesto que en la CPU existirá un "bit" que en todo momento indicará el modo en que se está ejecutando. Este se pondrá a 1 ó 0 cada vez que se produzca un cambio entre el SO y otro programa. Es de suponer que las instrucciones que permiten variar este "bit" son privilegiadas.

Da la impresión que con los aspectos antes indicados ya se tiene garantizada la protección de las entradas salidas, pero antes de dar tal afirmación se hace necesario estar seguro que ningún programa usuario pueda ejecutar en modo supervisor. ¿Qué pasaría si a un programa usuario se le permite realizar direccionamientos al área de memoria del sistema operativo y modificar un vector de interrupción? Al ocurrir la interrupción, el hardware pasará la ejecución al modo privilegiado (ya que va a operar el sistema operativo), pero como se cambió el vector de interrupción, nos encontramos que el programa usuario se hace dueño del sistema de cómputo con total impunidad.

Para evitar esta situación y otras similares se impone disponer de un mecanismo de protección de memoria. Es decir, evitar que un programa usuario pueda acceder al área de trabajo del Sistema Operativo. En los sistemas multiprogramados también se tiene que impedir tal acción en el área de otro programa.

La solución a esta problemática requiere que el hardware brinde su ayuda. En un ambiente de monoprogramación es suficiente con la existencia de unregistro tope o registro límite que separe el área de trabajo del sistema operativo de la correspondiente al programa usuario.

En este caso, generalmente el sistema operativo se ubica en la parte baja de la memoria y a continuación comenzaría el área del programa usuario. Cada vez que dicho programa realiza un acceso a memoria, el hardware chequea que la dirección referida no sea menor que la contenida en el registro a los efectos de permitirlo. Si se detecta el intento de penetrar en el área no autorizada ocurrirá una trampa invocándose al SO para que decida la situación (generalmente se elimina al que provoca "la ofensa").

El SO conserva la posibilidad de acceder cualquier posición de memoria (al correr en modo privilegiado el hardware no lo controla). Por supuesto la carga del registro indicado solo se puede hacer en modo "kernel".