Ingeniería en Informática

Sistemas Operativos

Trabajo Investigación Nº 2

“Estructuras del Sistema Operativo Sodium”

Nicanor CasasEquipo Graciela De Luca

Waldo ValienteDocente Gerardo Puyo

Sergio MartínFederico Díaz

Sebastian Deuteris

GRUPO Nº 3Días de Cursada: Miércoles/Viernes

Alumnos Apellido Nombre DNI

Calaz Alberto Ezequiel 30556899

Barboza Carvalho Pablo 27282874

Medina Gabriela 35111323

Acreditación:

Instancia Fecha CalificaciónENTREGA 01/07/15

ENTREGA TARDÍA 15/07//2012

Página 1

Índice

Desarrollo......................................................................................................................Pág. 3

Parte Teórica................................................................................................................Pág. 5

Parte Práctica.............................................................................................................Pág. 16

Conclusión..................................................................................................................Pág. 29

Página 2

Página 3

Desarrollo

Objetivo del Trabajo PrácticoEn este trabajo práctico se busca continuar con los esfuerzos de implementar la interfaz de visualización del sistema operativo. En particular, se orienta a la visualización de las diferentes estructuras que utiliza el Sistema Operativo a través de comandos de GDB, además de conocer sus interrelaciones y ubicaciones en memoria principal.

Alcance:Analizar la composición e interrelación entre las distintas estructuras del SistemaOperativo Sodium.Establecer la ubicación en memoria de los diferentes componentes del sistema entiempo real.Generar comandos de GDB que permitan cumplir con el objetivo del TP.

Página 4

Página 5

Resumen:En la parte teórica se ha analizado el código de Sodium y se desarrolló un informede la composición de los distintos items que conforman las siguientes estructurasdel Sistema operativo: GDT, IDT, PCB Y TSS. También se esquematizó lainterrelación existente entre ellos.Posteriormente se ha realizado un informe de las posiciones de memoria de lasestructuras anteriormente mencionadas, representandolas en un gráfco de lamemoria.

Página 6

Sistema Operativo: SODIUMGDT: (Tabla de descriptores globales) Es una estructura de datos en la que se defnen los selectores de segmentos que apuntan a las distintas áreas de memoria, utilizadas durante la ejecución del programa, incluyendo la dirección de base, el tamaño y los privilegios de accesos; y algunas tablas importantes para el sistema operativo, como lo son la TSS y la SS0 (que serán defnidas más adelante).Estructura básica en de la GDT:

GDT NULA

Selector de Segmento de Código

Selector de Segmento de Datos

Selector de Segmento de Stack

TSS

SSO

La tabla tiene 8192 (máximo) entradas, cada una de 8 bytes:

El registro que tiene la dirección de memoria donde se encuentra la GDT es GDTR que en Sodium se llama: pdwGDT, y esta inicializado en el archivo system.c.En SODIUM la estructura sería:

Página 7

La estructura del descriptor esta basada en:

Donde:

Página 8

Un ejemplo de la estructura de un descriptor para un proceso usuario (IDLE.BIN) sería:

IDT: (Tabla de descriptores de interrupción) Tabla que guarda los descriptores de interrupciones. Cada vez que se produce una interrupción, se salta a una entrada de esta tabla. Contiene 256 entradas, y cada entrada tiene información para llegar a una función manejadora de la interrupción. Contienen el campo denominado Selector, que tiene la dirección de una entrada de la tabla GDT; el campo Desplazamiento, que contiene el desplazamiento que hay que sumar a la base del nucleo para llegar a la función que queremos que se ejecute cuando se interrumpe; por ultimo contiene una serie de campos denominados Atributos, que fjan si el desplazamiento viene en bytes o en palabras (bits de protección, etc). Existe un registro IDTR dentro del microprocesador que contiene la dirección base y la longitud de esta tabla, para encontrarla con rapidez. Existe una tabla para todo el sistema. Para rellenar esta tabla se precisan instrucciones en ensamblador privilegiadas, un usuario normal no puede modifcar sus entradas.

El registro IDTR en Sodium se lo asocia a pstuIDT y se inicializa en system.c.

La tabla contiene descriptores de segmento especiales: Task gates Interrupt gates: Se utilizan para apuntar a los manejadores de interrupción y

a los servicios del sistema operativo. Trap gates: Se utilizan para apuntar a manejadores de excepciones.

Cada uno de los descriptores tiene un tamaño de 8 bytes y se divide en tres campos:

Atributos: Defne el tipo de gate, asi como el nivel de privilegio del mismo. Selector: El selector correspondiente al segmento que contiene la dirección

lógica en la que comienza el manejador. Desplazamiento: El desplazamiento correspondiente a la direcciones lógica en

la que comienza el manejador.

Página 9

En Sodium la estructura de la tabla IDT sería:

PCB: (Bloque de control del proceso) Es una estructura especial donde el sistema operativo agrupa toda la información que necesita conocer respecto a un proceso particular. Cada vez que se crea un proceso el sistema operativo crea el PCB correspondiente para que sirva como descripción en tiempo de ejecución durante toda la vida del proceso. Cuando el proceso termina, su PCB es borrado.

La información almacenada en un PCB incluye: Identifcador del proceso. Estado del proceso. Ej.: Listo, Bloqueado, Nuevo, Terminado, etc. Contador del programa: Dirección de la próxima instrucción a ejecutar. Valores de registro de CPU. Se utilizan también en el cambio de contexto. Espacio de direcciones de memoria. Prioridad en caso de utilizarse dicho algoritmo para planifcación de CPU. Lista de recursos asignados (incluyendo descriptores de archivos y sockets

abiertos). Estadísticas del proceso. Datos del propietario. Permisos asignados. Signals pendientes de ser servidos. Etc.

Página 10

Registro IDTR que tiene la dirección de la tabla IDT

Descriptores de segmentos

Cantidad de entradas de la

tabla IDT

La estructura del PCB en Sodium sería:

Página 11

//Posición en la TSS//Nombre del proceso//Tamaño del proceso

//Indica la cabecera de ELF

//Dirección base de la tabla SS0//Posición del stack

Un ejemplo del proceso IDLE.BIN sería:

TSS: (Segmento de estado de tareas) Es una lista con varias estructuras que contiene el estado de los registros en un momento dado. Se la utiliza para guardar el estado de los registros del proceso que sale, en un context switch.

Segmento de estado de tareaToda la información que el procesador necesita para manejar una tarea se almacena en un tipo especial de segmento llamado segmento de estado de tarea (TSS).

Existe una gran cantidad de información que es almacenada en el TSS. Dicha información la podemos dividir en dos grandes grupos:Un conjunto dinámico que el procesador actualiza con cada conmutación de tarea. En este conjunto se encuentran los siguientes campos del TSS:

Registros generales (EAX, EBX, EDX, ..., EDI).Registros de segmento (CS, ES, SS, DS, FS, GS)Registro de estado e instrucción (EFLAGS, EIP)El selector del TSS de la tarea ejecutada anteriormente

Un conjunto estático que el procesador lee pero no modifca. En este conjunto se encuentra el resto de campos del TSS.

Cuando se produce una intercambio de tarea, todo el TSS de la tarea original es

Página 12

cargado por el procesador a fn de recordar el estado de la tarea antes de conmutar. El procesador leerá el TSS de la tarea a la que se le pasa el control y recargará el contenido de sus registros con los valores que ha leído del TSS.Descriptor de TSSEn la GDT se almacenan también este tipo de descriptores que contienen información acerca de un segmento de memoria que almacena información acerca de un TSS.El formato de un descriptor de TSS contiene la misma información que cualquier otro descriptor normal de la GDT. El descriptor de TSS contiene por tanto el campo DPL, LIMITE, BASE, etc.Un procedimiento que tiene acceso a un descriptor de TSS, a través del campo DPL, puede realizar una conmutación de tareas. El tener acceso a dicho descriptor no implica que ese procedimiento pueda leer o modifcar el TSS.

Registro de tareaEl procesador contiene un registro llamado TR (registro de tarea) que identifca a la tarea que se está ejecutando apuntando al TSS de esa tarea. Al realizar un intercambio de tarea este registro es recargado a fn de apuntar al TSS de la nueva tarea.Existen instrucciones como LTR y STR que sirven para cargar y guardar el contenido del registro TR, aunque la mayoría de las veces el registro TR es cargado de forma implícita al realizar un salto sobre un descriptor TSS.Intercambio de tareasEl 80386 realiza una conmutación de tarea cuando la tarea original realiza un salto o una llamada (JMP o CALL) que remite a un descriptor TSS.Los pasos siguientes muestran el proceso de un intercambio de tareas:Comprobar que la tarea actual tiene permiso de cambiar a la tarea designada. Esta comprobación se realiza a través del campo DPL del descriptor TSS de la nueva tarea.Comprobar que el descriptor TSS está marcado como presente y tiene un límite válido (mayor o igual a 103).Guardar el estado de la tarea en curso. El procesador guarda en el TSS de la tarea actual el contenido de todos los registros del procesador.Cargar el registro de tareas (TR) con el selector del descriptor del TSS de la nueva tarea.Cargar el estado de la nueva tarea procedente de su TSS y continuar su ejecución.Como puede verse, la conmutación de una tarea a otra es realizada por el 80386 de una forma efciente y bastante fácil. La unica preocupación que tiene el programador es la de defnir cuidadosamente los descriptores TSS y defnir una área de datos estática para que sea utilizada por el procesador para guardar el estado de cada tarea.

Protección en puertos de Entrada y Salida (E/S)El 80386 posee instrucciones para acceder a los puertos de E/S, como IN y OUT, pero las comprobaciones que se hacen en éstas, antes de acceder a un puerto específco, son diferentes en el modo real y el modo protegido. Estas instrucciones poseen como operando la dirección de un puerto en el espacio de direcciones de entrada y salida.Existen dos mecanismos que dan protección a las funciones de entrada y salida:El campo IOPL en el registro EFLAGS determina el derecho a usar instrucciones

Página 13

relativas a entrada y salida.En el segmento del TSS existe un bit de permiso de entrada y salida para cada puerto de E/S, que especifca e derecho o no de acceder a un puerto específco.Estos mecanismos de protección sólo operan en el modo protegido y modo virtual 8086, pero no operan en el modo real. Por tanto, en el modo real se puede acceder libremente a cualquier puerto de E/S por cualquier programa, lo que puede suponer una fácil caída del sistema por parte de programas mal intencionados.

Interrelación de las tablas y estructuras vistas anteriormente:

Interrelación entre la tabla GDT y el PCB:

Las tablas GDT e IDT son inicializadas en main.c que está en modo protegido y esdonde se crea el primer proceso usuario ejecutado por el kernel: INIT.BIN.El PCB y la tabla TSS se inicializan en gdt.c.

Página 14

Representación de la Memoria:

Inicio Fin

Main.bin 000000 3790F

BSS 37910 41453

Heap Memoria Baja 52800 EFBFF

Heap Memoria Alta 1186A0 202445F

PCB 11E6AE 124AAD

GDT 42000 51FFF

IDT 52000 527FF

ROM-BIOS A0000 FFFFF

Biblioteca Dinámica 273BEC 279BEB

Idle.bin

CS 1DF84A 1E5849

DS 1DF84A 225849

TSS 124AB6 84DAB5

SS0 225852 1225851

Init.bin

CS 22CBE4 233BE3

DS 22CBE4 273DE3

TSS 1251DE 84E1DD

SS0 1D97B6 11D97B5

Sodshell.bin

CS 2C85BF 2D25BE

DS 2C85BF 3125BE

TSS 125906 84E905

SS0 22A9AB 122A9AA

Página 15

Página 16

Resumen:Se ha generado lo siguiente:

Set de comandos en PHYTON que permite ver la composición de las estructuras siguientes: GDT, IDT, PCB Y TSS.

Set de comandos en GDB que permite ver la conformación del mapa de memoria del sistema operativo.

Un script GDB que implementa los Puntos de Instrumentación para detectar los siguientes eventos y las operaciones a realizar para extraer información relevante desde GDB:Inicio del Shell del SOCarga en memoria de la Biblioteca Dinámica libiblio.binEliminación de la Biblioteca dinámica de la memoriaCreación de un proceso, indicando para ello:Su pidLa posición de memoria donde está ubicadoSu tamaño en memoriaFinalización de la ejecución de un proceso

Modifcación de Sodium para que no se puedan interrumpir las funciones encarga-das de realizar el malloc y el free en el sistema operativo al momento de ocurrir una IRQ.

Página 17

Set de comandos en PHYTON que permite ver la composición de las estructuras siguientes: GDT, IDT, PCB Y TSS: guiGDB

El comando guiGDB despliega una ventana que muestra un Menu Principal donde se puede elegir:

El primer botón: guigdb permite que se ingrese un comando:

Página 18

Ingresar un comando a ejecutar

Ingresar el numero de registro de

alguna de las estructuras para ver su contenido.

Contenido de la estructura PCB en la posición 1

que es el proceso INIT.BIN

En cambio, eligiendo el segundo botón: Estructuras Sodium se obtendrá lo siguiente:

Aquí se puede escoger que estructura de Sodium ver, si se elige GDT se obtendrá:

Página 19

Se quiere observar el

contenido de la tabla GDT

en la posición 13.

Se obtendrá

En el registro Acceso son 8bits, o sea 256 opciones, que son los de P/DPL/S/TYPE

1bit P = 0 - Segmento no presente en memoria1bit P = 1 - Segmento presente en memoria2 bits DPL = 0 - Nivel de privilegio 02 bits DPL = 1 - Nivel de privilegio 12 bits DPL = 2 - Nivel de privilegio 22 bits DPL = 3 - Nivel de privilegio 31bit S = 0 - Segmento de Sistema1bit S = 1 - Segmento Codigo o Datos4bits TYPE 0 a 15 segun si es codigo/datos o Sistema.

Que se condice con los siguientes cuadros:

Página 20

Si se escoge IDT:

Si se elige TSS como estructura:

Página 21

Numero de descriptor a

observar

Tipo de descriptor de interrupción.

Muestra

Características del descriptor.

Rutina de atención de

interrupciones para ese descriptor.

Pid del proceso para el cual se

quiere observar la estructura de la

tabla TSS. En este caso el pid 2 hace

referencia al proceso usuario: SODSHELL.BIN

Se obtiene la siguiente información:

Por ultimo, si lo que se quisiese ver es la estructura PCB:

Se verá:

Página 22

Registros de la tabla

TSS

Pid del proceso para el cual se

quiere observar la estructura del

PCB.

Set de comandos en GDB que permite ver la conformación del mapa de memoria del sistema operativo: “mapaMemoria”

El comando mapaMemoria informa en qué lugar de la memoria comienzan y fnalizan las estructuras básicas del sistema operativo.

Inicialmente muestra Main.bin, BSS, Heap memoria baja, Heap memoria alta, PCB, GDT, IDT, el área de ROM-BIOS, libiblio.bin y fnalmente los procesos de usuario.

PCBLa posición inicial está dada por el puntero a la misma; por lo cual basta con el

comando print pstuPCB.La última posición está dada por el sizeof de cada posición del PCB, multiplicado

por la cantidad de procesos que el sistema resiste (la constante CANTMAXPROCS) y a eso restarle una posición.

El comando necesario es print(void*)pstuPCB+sizeof(stuPCB)*CANTMAXPROCS-1.

El casteo a void* es necesario, dado que sin él, al restar 1, resta 1*sizeof(stuPCB), es decir, 512.

GDTLa posición inicial está dada por el puntero a la misma; por lo cual basta con el

comando print pstuTablaGdtDe manera similar al PCB, la Tabla GDT es un vector, y su última posición se

obtiene con el siguiente comando:print (void*)&(pstuTablaGdt->stuGdtDescriptorDescs[8192])-1

Página 23

IDTLa posición inicial está dada por el puntero a la misma; por lo cual basta con el

comando print pstuIDTComo la IDT es una simple estructura, su ultima posición de memoria es la posición

inicial + sizeof(stuIDT) -1, y el comando necesario para encontrarla es print (void*)pstuIDT+sizeof(stuIDT)-1

ROM-BIOSEl área de ROM-BIOS está defnida en la arquitectura del microprocesador, y debe

ser desde A0000 hasta FFFFF, por lo cual en este comando está hardcodeado.

libiblio.bin y Procesos de UsuarioLos comandos que obtienen estos datos son busca_ES y muestraProcesosUsuario,

que serán explicados a continuación

PROCESOS DE USUARIO:Estos procesos son un poco más complejos de obtener, dado que cada uno tiene cuatro estructuras que nos interesan, y sus posiciones de memoria están indicadas en la tabla GDT, pero en las entradas en las cuales el PCB indique.

El procedimiento para obtener el mapa de un proceso de usuario es:Entrar a la posición de PCB correspondiente al PID de ese proceso, por ejemplo: el

PID 1 (init.bin) está en pstuPCB[1]Buscar en esa posición (pstuPCB[1]) las variables que nos interesan:

uiIndiceGDT_CS, uiIndiceGDT_DS, uiIndiceGDT_TSS, uiIndiceGDT_SS0 Estas variables corresponden a las posiciones de la tablaGDT que contienen la

información que buscamos; supongamos que uiIndiceGDT_CS es 12En ese caso, la posición 12 de la tablaGDT tendrá la información necesaria para

saber en qué posición comienza y en qué posición termina el segmento de datos de init.bin

De cada posición de la GDT tendremos que analizar seis variables: bitGranularidad, usBaseBajo, ucBaseMedio, usBaseAlto, usLimiteBajo, bitLimiteAlto.

La dirección base de cada segmento estará dada por la concatenación de usBaseAlto | ucBaseMedio | usBaseBajo. Para lograr dicha concatenación, hay que shiftear usBaseAlto 24 posiciones, y ucBaseMedio 16 posiciones.

El fnal de cada segmento estará dado por suposición inicial + tamaño de segmento – 1.El tamaño de segmento se obtiene de las variables bitGranularidad, usLimiteBajo y

bitLimiteAlto.Si la granularidad es 4, el tamaño del segmento será la concatenación

de(bitLimiteAlto | usLimiteBajo )+ 1 , si la granularidad es 12, hay que multiplicar a dicha concatenación por 4096.

Un ejemplo:Supongamos bitLimiteAlto= 0x1, y usLimiteBajo=0xab12.En caso que la granularidad sea 4, el tamaño de segmento será 0x1ab13, pero si la

granularidad es 12, el tamaño de segmento será 0x1ab13000.Acercándonos un poco más al código que obtiene estos datos:El comando muestraProcesosUsuario se encarga de llamar adecuadamente al

Página 24

comando datosPID. Este ultimo comando es el encargado de obtener los datos.Debe recibir dos parámetros: el PID del cual quiere obtener los datos, y el segmento que se busca (CS, DS, SSO o TSS).Una invocación correcta a ese comando sería datosPid 1 CS (que obtiene la información del segmento de código de init.bin). El comando datosPid NO hace validaciones de sus parámetros, dado que sólo debe ser invocado desde muestraProcesosUsuario.

El funcionamiento de datosPid es así:Sabiendo que el primer parámetro recibido (numérico, corresponde al PID) es $arg0, y el segundo (CS, DS, SSO o TSS) es $arg1, podemos utilizar la siguiente línea:

set $granularidad=pstuTablaGdt ->stuGdtDescriptorDescs[pstuPCB[$arg0].uiIndiceGDT_$arg1].bitGranularidad

Siendo [pstuPCB[$arg0].uiIndiceGDT_$arg1] simplemente el índice de la tabla GDT en la que queremos buscar la granularidad, o el dato que sea.Luego, obteniendo las seis variables ya mencionadas en el punto 2, obtendremos la dirección base, y el tamaño de segmento.

Es decir: datosPID tiene la lógica para obtener la información necesaria, y muestraProcesosUsuario llama a datosPID de la manera correcta.

Finalmente, el comando busca_ES recorre el vector de PCB, y por cada proceso encontrado busca en la variable uiIndiceGDT_ES la entrada GDT_ES asociada a ese PID. Si la granularidad de esa entrada GDT es 12, corresponde a libiblio, y el procedimiento para obtener su inicio y su fn es idéntico al de los otros datos de cada proceso de usuario.

El comando mapaMemoria muestra por pantalla el tamaño de algunos de los elementos de Sodium:

Página 25

Modifcación de Sodium para que no se puedan interrumpir las funciones encar-gadas de realizar el malloc y el free en el sistema operativo al momento de ocu-rrir una IRQ.

Para que no se puedan interrumpir las funciones malloc y free en el sistema operati-vo, del lado kernel, se han implementado funciones de Habilitar y Deshabilitar Inte-rrupciones que se encuentran en el archivo: kernel/system.c del Sistema Operati-vo Sodium.Las funciones son:

Se realizó lo siguiente:

Las funciones malloc() y free() llaman a pvFnMalloc() y a iFnFree(), pero gestionando interrupciones (en modo Kernel).

Página 26

/common/sodheap.c

iFnFree();

Procesos Usuarios

Kernel

pvFnMalloc();

malloc();

free();

Un script GDB que implementa los Puntos de Instrumentación para detectar los siguientes eventos y las operaciones a realizar para extraer información relevante desde GDB:Inicio del Shell del SOCarga en memoria de la Biblioteca Dinámica libiblio.binEliminación de la Biblioteca dinámica de la memoriaCreación de un proceso, indicando para ello:Su pidLa posición de memoria donde está ubicadoSu tamaño en memoriaFinalización de la ejecución de un proceso

Se ha generado un script en Phyton que envía mensajes con los puntos de Instru-mentación como van ocurriendo.

Las ventanas que se muestran son:

Página 27

Página 28

Página 29

Conclusión:En este trabajo práctico se ha trabajado la visualización de contenido de lasestructuras analizadas en la teoría, con detenimiento. Hemos aprendido elfuncionamiento interno del sistema operativo Sodium y hemos podido relacionarconceptos aprendidos con otras materias. Aprendimos a utilizar un repositorio dedatos, a trabajar en equipo de una manera organizada, para evitarle futurosproblemas a los compañeros y sobre todo adquirimos muchísimos conocimientos,unos de otros, que se obtuvieron tanto laboral como académicamente.

Página 30