ES2209969T3 - Protocolo de gestion, procedimiento de verificacion y de transformacion de un fragmento de programa descargado y sistemas correspondientes. - Google Patents

Abstract

Protocolo de gestión de un fragmento de programa descargado en un sistema portable reprogramable, tal como una tarjeta con microprocesador provisto de una memoria de lectura - escritura, el mencionado fragmento de programa está constituido por un código objeto, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros o variables locales manipulados por estas instrucciones y que permiten interpretar este código objeto, el mencionado sistema portable está interconectado a un terminal, caracterizado por el hecho de que este protocolo consiste al menos, al nivel del mencionado sistema portable: a) en detectar un comando de descarga de este fragmento de programa; y con una respuesta positiva en esta etapa que consiste en detectar un comando de descarga, b) en leer el código objetivo que constituye este fragmento de programa y en memorizar temporalmente este código objeto; c) en someter elconjunto del código objeto memorizado temporalmente a un proceso de verificación instrucción por instrucción, este proceso de verificación consiste al menos en una etapa de inicialización de la pila de los tipos en un estado de vacío y de la tabla de los tipos de registros a un tipo que representa la intersección de todos los tipos de datos, que representan el estado de la mencionada máquina virtual al principio de la ejecución del código objeto memorizado temporalmente y en una sucesión de etapas de verificación, instrucción por instrucción, por discriminación de la existencia, para cada instrucción corriente, de un objetivo, objetivo de instrucción de conexión, objetivo de una llamada de un gestor de excepciones u objetivo de una llamada de sub-rutina y por una verificación y una actualización del efecto de la mencionada instrucción corriente sobre la pila de los tipos y sobre la tabla de los tipos de registros, y, en el caso de una verificación lograda del mencionado código objeto, d) enregistrar el fragmento de programa descargado en un repertorio de fragmentos de programas disponibles, y, en el caso de una verificación no lograda del mencionado código objeto, e) en inhibir la ejecución, en el sistema portable, del mencionado fragmento de programa.

Description

Protocolo de gestión, procedimiento de verificación y de transformación de un fragmento de programa descargado y sistemas correspondientes.

La invención se refiere a un protocolo de gestión, un procedimiento de comprobación, un procedimiento de transformación de un fragmento de programa descargado y los sistemas correspondientes, más particularmente destinados a los sistemas informáticos portables que disponen de débiles recursos de memoria y de potencia de cálculo.

De un modo general, con referencia a la figura 1a, se recuerda que los sistemas informáticos portables (10) constan de un microprocesador (11), una memoria permanente, tal como una memoria no de lectura - escritura (12) que contiene el código del programa ejecutable, una memoria permanente, no volátil, de lectura - escritura (13) del tipo EEPROM que contiene los datos almacenados en el sistema, una memoria viva, volátil (14), en la cual el programa almacena sus resultados intermedios durante su ejecución, y unos dispositivos de entrada / salida (15) que permiten al sistema de interactuar con su entorno. En el caso en que el sistema informático portable está constituido por una tarjeta con microprocesador, del tipo de tarjeta bancaria, el dispositivo de entrada / salida (15) consiste en una unión en serie que permite a la tarjeta comunicar con un terminal, tal como un terminal lector de tarjetas.

En los sistemas informáticos portables clásicos, el código del programa ejecutado por el sistema está fingido durante la construcción del sistema, o, como muy tarde, durante la personalización de este último antes de la entrega al usuario final.

Sin embargo, se han puesto en práctica unos sistemas informáticos portables más evolucionados, estos sistemas son reprogramables, como por ejemplo las tarjetas con microprocesador del tipo JavaCard. Estos sistemas programables añaden, en relación con los precedentes, la posibilidad de enriquecer el programa después de la puesta en servicio del sistema, por una operación de descarga de fragmentos de programas. Estos fragmentos de programas, comúnmente designados por "applets" en el lenguaje anglo-sajón, serán designados de modo indiferente por aplicaciones o fragmentos de programas en la presente descripción. Para una descripción más detallada de los sistemas JavaCard, se podrá de modo útil referirse a la documentación editada por la sociedad SUN MICROSYSTEMS INC. Y en particular a la documentación disponible electrónicamente, capítulo tecnología JavaCard en el lugar W.W.W. (World Wide Web) http://java.sun.com/products/javacard/index.html, junio 1999.

La figura 1b ilustra la arquitectura de tal sistema informático portable reprogramable. Esta arquitectura es similar a la de un. sistema portable clásico, con la diferencia que el sistema portable reprogramable puede además recibir aplicaciones por medio de uno de sus dispositivos de entrada / salida, luego almacenar estos últimos en su memoria permanente (13) a partir de la que a continuación se pueden ejecutar como complemento al programa principal.

Por motivos de portabilidad entre los diferentes sistemas informáticos portables, las aplicaciones se presentan en forma de código para una máquina virtual standard. Este código no es directamente ejecutable por el microprocesador (11) pero debe ser interpretado del modo lógico por una máquina virtual (16), que está constituida por un programa residente en memoria permanente no de lectura - escritura (12). En el ejemplo anteriormente citado de las tarjetas JavaCard, la máquina virtual utilizada es un sub-conjunto de la máquina virtual Java. Para una descripción de las especificaciones en relación con la máquina virtual Java y de la máquina virtual utilizada, se podrá útilmente referirse a la obra publicada por Tim LINDHOLM y Frank YELLIN, titulada "The Java Virtual Machine Specificacion", Addison-Wesley 1996, y a la documentación editada por la Sociedad SUN MICROSYSTEMS INC. "JavaCard 2.1. Virtual Machine Specification", documentación disponible electrónicamente en el lugar W.W.W. http://java.sun.com/products/javacard/JCVMSpec.pdf, marzo 1999.

La operación de descarga de la aplicación en un sistema informático portable en servicio presenta importantes problemas de seguridad. Una aplicación mal escrita de modo involuntario, hasta voluntario, puede modificar de modo incorrecto unos datos presentes en el sistema, impedir que el programa principal se ejecute correctamente o en un tiempo deseado, o aún modificar otras aplicaciones descargadas anteriormente, haciéndoles inutilizables o dañinas.

Una aplicación escrita por un pirata informático puede igualmente divulgar informaciones confidenciales almacenadas en el sistema, informaciones tales como el código de acceso en el caso de una tarjeta bancaria por ejemplo.

En la actualidad, se han propuesto tres soluciones con vistas a remediar el problema de seguridad de las aplicaciones.

Una primera solución consiste en utilizar unas firmas criptográficas con el fin de solo aceptar unas aplicaciones procedentes de personas o de organismos de confianza. En el ejemplo de una tarjeta bancaria anteriormente citado, solo las aplicaciones que llevan la firma criptográfica del banco que haya emitido la tarjeta son aceptadas y ejecutadas por la tarjeta, toda otra aplicación no firmada es rechazada en el transcurso de la operación de descarga. Un usuario mal intencionado de la tarjeta, que no tiene claves numéricas del banco, no será por tanto capaz de hacer ejecutar una aplicación no firmada y peligrosa en la tarjeta. Esta primera solución está bien adaptada al caso en que todas las aplicaciones proceden de una misma fuente única, el banco en el ejemplo anteriormente citado. Esta solución es difícilmente aplicable al caso en que las aplicaciones proceden de varias fuentes, como, en el ejemplo de una tarjeta bancaria, el fabricante de la tarjeta, el banco, los organismos de gestión de los servicios por la tarjeta bancaria, los grandes organismos de distribución comercial que ofrecen a la clientela unos programas de fidelización y que proponen, legítimamente, descargar unas aplicaciones específicas en la tarjeta. La compartición y la detención entre estos diferentes actores económicos de las claves numéricas necesarias para la firma electrónica de las aplicaciones presentan unos problemas técnicos, económicos y jurídicos principales.

Una segunda solución consiste en llevar a cabo unos controles dinámicos de acceso y de tipo durante la ejecución de las aplicaciones.

En esta solución, la máquina virtual durante la ejecución de las aplicaciones lleva a cabo una cierta cantidad de controles, tales como:

-

el control de acceso a la memoria: en cada lectura o escritura de una zona de memoria, la máquina virtual comprueba el derecho de acceso de la aplicación a los datos correspondientes;

-

la comprobación dinámica de los tipos de datos: en cada instrucción de la aplicación, la máquina virtual comprueba que se satisfacen las restricciones en los tipos de datos. A título de ejemplo, la máquina virtual puede tratar especialmente los datos tales como unas direcciones de memoria válidas e impedir que la aplicación engendre unas direcciones de memoria inválidas por medio de conversiones entera / dirección o de operaciones aritméticas en las direcciones:

-

la detección de los desbordamientos de pila y de los accesos ilegales en la pila de ejecución de la máquina virtual, que, en ciertas condiciones, son susceptibles de perturbar el funcionamiento de la última, al punto de eludir los mecanismos de control precedentes.

Esta segunda solución permite la ejecución de una gran gama de aplicaciones en unas condiciones de seguridad satisfactorias. Sin embargo presenta el inconveniente de una reducción considerable de la velocidad de la ejecución, provocada por el conjunto de las verificaciones dinámicas. Para obtener una reducción de esta reducción de velocidad, una parte de estas comprobaciones puede ser llevada a cabo por el microprocesador mismo, sin embargo al precio de un aumento de la complejidad de este último y por tanto en el precio de coste del sistema portable. Tales verificaciones aumentan además las necesidades de memoria viva y permanente del sistema, a razón de las informaciones suplementarias de tipo que es necesario asociar a los datos manipulados.

Una tercera solución consiste en llevar a cabo una comprobación estática del código de la aplicación durante la descarga. En esta solución, esta comprobación estática simula la ejecución de la aplicación al nivel de los tipos de datos y establece, una vez por todas, que el código de la aplicación respeta la regla de los tipos de datos y de control de acceso impuesta por la máquina virtual y no provoca desbordamiento de pila. Si esta verificación estática se logra, la aplicación puede entonces ser ejecutada sin que sea necesario comprobar de modo dinámico que esta norma sea respetada. En el caso en que el proceso de comprobación estática falla, el sistema portable rechaza la "aplicación" y no permite su ejecución ulterior. Para una descripción más detallada de la tercera solución anteriormente citada, se podrá de modo útil referirse a la obra editada por Tim LINDHOLM y Frank YELLIN, anteriormente citada, al artículo publicado por James A. GOSLING, titulado "Java Intermediate Byte Codes", Documentos de ACM SIGPLAN, Taller sobre Representaciones Intermedias (IR '95), páginas 111-118, enero 1995, y a la patente US 5.748.964 entregada el 05/05/1998.

En relación con la segunda solución, la tercera solución presenta la ventaja de una ejecución de las aplicaciones de modo mucho más rápido, ya que la máquina virtual no lleva a cabo ninguna comprobación durante la ejecución. Sin embargo, la tercera solución presenta el inconveniente de un proceso de verificación estática del código complejo y costoso, tanto en tamaño del código necesario para conducir este proceso, como en el tamaño de la memoria viva necesaria para contener los resultados intermedios de la comprobación, y en el tiempo de cálculo. A título de ejemplo de ilustración, la comprobación del código integrado en el sistema Java JDK comercializado por SUN MICROSYSTEMS representa del orden de 50 k-octetos de código de máquina, y su consumo de memoria viva es proporcional a (Tp + Tr) x Nb donde, (Tp) designa el espacio máximo de pila, Tr designa la cantidad máxima de registros y (Nb) designa la cantidad máxima de objetivos de unas conexiones utilizadas por un sub-programa, aún comúnmente designado por método, de la aplicación. Estas necesidades de memoria sobrepasan ampliamente las capacidades de los recursos de la mayoría de los sistemas informáticos portables actuales, notablemente de las tarjetas con microprocesador comercialmente disponibles. Se han propuesto varias variantes de la tercera solución, en las cuales el editor de la aplicación transmite al comprobador, aparte del código de la aplicación, un cierto número de informaciones suplementarias específicas tales como los tipos de datos calculados previamente o prueba establecida previamente de la tipificación de datos correcta. Para una descripción más detallada de los modos de operación correspondientes, se podrá de modo útil referirse a los artículos publicados por Eva ROSE y Kristoffer HOGSBRO ROSE, "Lightweight Bytecode Vérification", Documentos del Workshop Formal Underspinning de Java, Octubre 1998, y por George C. NECULA, "Proof-Carrying Code", Documentos del 24^{e} ACM Principios de Simposio de Lenguajes de Programación, páginas 106-119 respectivamente. Estas informaciones suplementarias permiten comprobar el código con mayor rapidez y reducir ligeramente el tamaño del código del programa de verificación pero sin embargo no permiten reducir las necesidades de memoria viva, hasta las aumentan, de modo muy importante, en el caso de informaciones de prueba establecidas previamente de la tipificación de datos correcta.

La presente invención tiene como objeto remediar los inconvenientes anteriormente citados del tipo previo.

En particular, es un objeto de la presente invención la puesta en práctica de un protocolo de gestión de un fragmento de programa, o aplicación, descargado que permite una ejecución de este último por un sistema informático portable que dispone de débiles recursos, tal como una tarjeta de microprocesador.

Es igualmente otro objeto de la presente convención la puesta en práctica de un procedimiento de comprobación de un programa, o aplicación, descargado, en el cual se lleva a cabo un proceso de comprobación estática del código de la aplicación durante su descarga, este proceso puede ser aproximado, al menos en su principio, de la tercera solución anteriormente descrita, pero en la cual se introducen unas nuevas técnicas de comprobación, con el fin de permitir la ejecución de esta comprobación en los límites de valores de talla de memoria y de velocidad de cálculo impuestos por las tarjetas con microprocesador y otros sistemas informáticos portables poco potentes.

Otro objeto de la presente invención es igualmente la puesta en práctica de procedimientos de transformación de fragmentos de programas de tipo clásico obtenidos por ejemplo por la puesta en práctica de un compilador Java en fragmentos de programa, o aplicaciones, normalizados, que satisfacen a priori a los criterios de comprobación del procedimiento de verificación objeto de la invención, con vistas a acelerar el proceso de comprobación y de ejecución de estos últimos a nivel de los sistemas informáticos portables o tarjetas con microprocesador actuales.

Finalmente, es otro objeto de la invención, la realización de sistemas informáticos portables que permiten la puesta en práctica del protocolo de gestión y del procedimiento de verificación de un fragmento de programa descargado, anteriormente mencionados, así como de sistemas informáticos que permiten la puesta en práctica de los procedimientos de transformación de fragmentos de programas, o aplicaciones, clásicos en fragmentos de programas, o aplicaciones, normalizados previamente mencionados.

El protocolo de gestión de un fragmento de programa descargado en un sistema portable reprogramable, objeto de la presente invención, se aplica notablemente a una tarjeta con microprocesador provisto de una memoria de lectura - escritura. El fragmento de programa está constituido por un código objeto, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros o variables locales manipulados por estas instrucciones y que permiten interpretar este código objeto. El sistema portable está interconectado con un terminal. Es notable en que consiste al menos, al nivel del sistema portable, para detectar un comando de descarga del fragmento del programa. En una respuesta positiva en la etapa que consiste en detectar un comando de descarga, consiste además en leer el código objeto que constituye el fragmento de programa y en memorizar temporalmente este código objeto en la memoria de lectura - escritura. El conjunto del código objeto memorizado está sometido a un proceso de comprobación, instrucción por instrucción. El proceso de verificación consiste al menos en una etapa de inicialización de la pila de los tipos y de la tabla de los tipos de registros que representa el estado de la máquina virtual al principio de la ejecución del código objeto memorizado temporalmente y en una sucesión de etapas de verificación instrucción por instrucción de la existencia, para cada instrucción corriente, de un objetivo, objetivo de instrucción de conexión, objetivo de un gestor de excepciones, y en una verificación y una actualización del efecto de la instrucción corriente en la pila de los tipos y en la tabla de los tipos de registros. En el caso de una verificación no lograda del código objeto, el protocolo objeto de la invención consiste en borrar el fragmento de programa registrado temporalmente, en la ausencia de registro de este último en el repertorio de fragmentos de programas disponibles, y a dirigir al lector un código de error.

El procedimiento de comprobación de un fragmento de programa descargado en un sistema portable, objeto de la invención, se aplica notablemente a una tarjeta con microprocesador provista de una memoria de lectura - escritura. El fragmento de programa está constituido por un código objeto y consta al menos de un sub-programa, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros de operandos manipulados por estas instrucciones y que permite interpretar este código objeto. El sistema portable está interconectado a un lector. Es notable por el hecho de que, como continuación a la detección de un comando de descarga y a la puesta en memoria del código objeto que constituye el fragmento de programa en la memoria de lectura - escritura, consiste, para cada sub-programa, en llevar a cabo una etapa de inicialización de la pila de los tipos y de la tabla de los tipos de registros por unos datos que representan el estado de la máquina virtual al principio de la ejecución del código objeto memorizado temporalmente, a llevar a cabo una comprobación del código objeto memorizado temporalmente, instrucción por instrucción, por discriminación de la existencia, para cada instrucción corriente, de un objetivo de instrucción de conexión, de un objetivo de un aparato de un gestor de excepciones o de un objetivo de una llamada de sub-rutina y a llevar a cabo una verificación y una actualización del efecto de la instrucción corriente sobre los tipos de datos de la pila de los tipos y de la tabla de los tipos de registros, en función de la existencia de un objetivo de instrucción de conexión, de un objetivo de una llamada de sub-rutina o de un objetivo de una llamada de gestor de excepciones. La comprobación se ha logrado cuando la tabla de los tipos de registros no se modifica a lo largo de una comprobación de todas las instrucciones, el proceso de verificación es seguido, instrucción por instrucción hasta que la tabla de los tipos de registros sea estable, en ausencia de modificación. Si no el proceso de verificación se interrumpe.

El procedimiento de transformación de un código objeto de un fragmento de programa en un código objeto normalizado para este mismo fragmento de programa, objeto de la presente invención, se aplica a un código objeto de un fragmento de programa en el cual los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, la pila de ejecución no presente un fenómeno de desbordamiento y para cada instrucción de conexión el tipo de variables de la pila al nivel de esta conexión es el mismo que al nivel de los objetivos de esta conexión. El código objeto normalizado obtenido es tal que los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, la pila de ejecución no presenta un fenómeno de desbordamiento y la pila de ejecución está vacía en cada instrucción de objetivo de conexión. Es notable por el hecho de que consiste, para el conjunto de las instrucciones del código objeto, en anotar cada instrucción corriente por el tipo de datos de la pila de ejecución antes y después de la ejecución de esta instrucción, los datos de anotación se calculan por medio de un análisis del flujo de datos relativos a esta instrucción, a detectar en el seno de las instrucciones, y de cada instrucción corriente, la existencia de conexiones para las cuales la pila de ejecución no está vacía, la operación de detección es llevada a partir de los datos de anotación del tipo de variables de pila permitidas a cada instrucción corriente. En la presencia de una detección de una pila de ejecución no vacía, consiste además en insertar unas instrucciones de transferencia de las variables de pila por una y otra parte de estas conexiones o de estos objetivos de conexión con el fin de vaciar el contenido de la pila de ejecución en unos registros temporales antes de esta conexión y restablecer la pila de ejecución a partir de los registros temporales después de esta conexión y si no de no insertar ninguna instrucción de transferencia. Este procedimiento permite así obtener un código de objeto normalizado para este mismo fragmento de programa, en el cual la pila de ejecución está vacía en cada instrucción de conexión y de objetivo de conexión, en ausencia de toda modificación de la ejecución del fragmento de programa.

El procedimiento de transformación de un código objeto de un fragmento de programa, en un código objeto normalizado para este mismo fragmento de programa, objeto de la presente invención, se aplica, además, a un código objeto de un fragmento de programa en el cual los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, y un operando de tipo determinado escrito en un registro por una instrucción de este código objeto es leído de nuevo desde ese mismo registro por otra instrucción de este código objeto con el mismo tipo de dato determinado. El código objeto normalizado obtenido es tal que los operandos pertenecen a los tipos de datos manipulados por esta instrucción, un solo y mismo tipo de datos está asignado a un mismo registro en todo el código objeto normalizado. Es notable por el hecho de que consiste, para el conjunto de las instrucciones del código objeto, en anotar cada instrucción corriente por el tipo de datos de los registros antes y después de la ejecución de esta instrucción, los datos de anotación son calculados por medio de un análisis del flujo de datos en relación con esta instrucción, y en llevar a cabo una nueva asignación de los registros de origen empleados con unos tipos diferentes, por división de estos registros de origen en registros normalizados distintos. Un registro normalizado es permitido para cada tipo de dato utilizado. Se lleva a cabo una nueva actualización de las instrucciones que manipulan los operandos que emplean los registros normalizados.

El protocolo de gestión de un fragmento de programa, el procedimiento de verificación de un fragmento de programa, los procedimientos de transformación de código objeto de fragmentos de programas en código objeto normalizado y los sistemas correspondientes, objetos de la presente invención, encuentran aplicación en el desarrollo de los sistemas portables reprogramables, tales como tarjetas con microprocesador, notablemente en el entorno Java.

Se comprenderá mejor con la lectura de la descripción y con la observación de los dibujos seguidamente indicados, aparte de las figuras 1a y 1b relativas al tipo previo, en los cuales:

- la figura 2 representa un organigrama ilustrativo del protocolo de gestión de un fragmento de programa descargado en un sistema portable reprogramable,

- la figura 3a representa, a título de ilustración, un organigrama de un procedimiento de comprobación de un fragmento de programa descargado conforme al objeto de la presente invención,

- la figura 3b representa un diagrama ilustrativo de los tipos de datos y de las relaciones de sub-tipo puesta en práctica por el procedimiento de gestión y el procedimiento de verificación de un fragmento de programa descargado, objeto de la presente invención,

- la figura 3c representa un detalle del procedimiento de comprobación de acuerdo con la figura 3a en relación con la gestión de una instrucción de conexión.

- la figura 3d representa un detalle del procedimiento de comprobación de acuerdo con la figura 3a en relación con la gestión de una instrucción de llamada de sub-rutina.

- la figura 3e representa un detalle del procedimiento de comprobación de acuerdo con la figura 3a en relación con la gestión de un objetivo de un gestor de excepciones

- la figura 3f representa un detalle del procedimiento de comprobación de acuerdo con la figura 3a en relación con la gestión de un objetivo de conexiones incompatibles,

- la figura 3g representa un detalle del procedimiento de comprobación de acuerdo con la figura 3a en relación con la gestión de una ausencia de un objetivo de conexión.

- la figura 3h representa un detalle del procedimiento de comprobación de acuerdo con la figura 3a en relación con la gestión del efecto de la instrucción corriente sobre la pila de tipos,

- la figura 3i representa un detalle del procedimiento de comprobación de acuerdo con la figura 3a en relación con la gestión de una instrucción de lectura de un registro,

- la figura 3j representa un detalle del procedimiento de comprobación de acuerdo con la figura 3a en relación con la gestión de una instrucción de escritura de un registro.

- la figura 4a representa un organigrama ilustrativo de un procedimiento de transformación de un código objeto de un fragmento de programa en un código objeto normalizado para este mismo fragmento de programa con instrucción de conexión respectivamente del objetivo de conexión con pila vacía,

- la figura 4b representa un organigrama ilustrativo de un procedimiento de transformación de un código objeto de un fragmento de programa en un código objeto normalizado para este mismo fragmento de programa haciendo uso de unos registros tipificados, a cada registro está atribuido un solo tipo de dato específico,

- la figura 5a representa un detalle de puesta en práctica del procedimiento de transformación ilustrado en la figura 4a,

- la figura 5b representa un detalle de puesta en práctica del procedimiento de transformación ilustrado en la figura 4b,

- la figura 6 representa un esquema funcional de la arquitectura completa de un sistema de desarrollo de un fragmento de programa normalizado, y de una tarjeta con microprocesador reprogramable que permite la puesta en práctica del protocolo de gestión y del procedimiento de verificación de un fragmento de programa conforme al objeto de la presente invención.

De un modo general, se indica que el protocolo de gestión, el procedimiento de verificación y de transformación de un fragmento de programa descargado, objeto de la presente invención, así como los sistemas correspondientes, están puestos en práctica gracias a una arquitectura lógica para la descarga y la ejecución con seguridad de aplicaciones en un sistema informático portable que dispone de débiles recursos, tal como notablemente las tarjetas con microprocesador.

De un modo general, se indica que la descripción que sigue se refiere a la aplicación de la invención en el contexto de las tarjetas con microprocesador reprogramables del tipo JavaCard, véase documentación disponible electrónicamente ante la sociedad SUN MICROSYSTEMS INC. rubrica JavaCard Technology anteriormente mencionada en la descripción.

Sin embargo, la presente invención es aplicable a todo sistema portable reprogramable por medio de una descarga de una aplicación escrita en el código de una máquina virtual que consta de una pila de ejecución, de registros o variables locales y cuyo modelo de ejecución está fuertemente tipificado, cada instrucción del código de la aplicación solo se aplica a unos tipos de datos específicos. El protocolo de gestión de un fragmento de programa descargado en un sistema portable reprogramable, objeto de la presente invención, se describirá ahora de modo más detallado en relación a la figura 2.

En relación con la figura anteriormente citada, se indica que el código objeto que constituye el fragmento del programa o aplicación está constituido por una secuencia de instrucciones ejecutables por el microprocesador del sistema portable por medio de la máquina virtual anteriormente mencionada. La máquina virtual permite interpretar el código objeto anteriormente citado. El sistema portable está interconectado con un terminal por medio de un enlace de serie por ejemplo.

Con referencia a la figura 2 anteriormente mencionada, el protocolo de gestión objeto de la presente invención consiste al menos, al nivel del sistema portable, para detectar en una etapa (100a, 100b) un comando de descarga de este fragmento de programa. De esta forma, la etapa (100a) puede consistir en una etapa de lectura del comando anteriormente citado y la etapa (100b) en una etapa de prueba de comando leído y de verificación de la existencia de un comando de descarga.

Con una respuesta positiva en la etapa de detección (100a, 100b) anteriormente citada de un comando de descarga, el protocolo objeto de la presente invención consiste a continuación en leer en la etapa (101) el código objeto que constituye el fragmento de programa considerado y memorizar temporalmente el código objeto anteriormente citado en la memoria del sistema informático portable. La operación de memorización temporal anteriormente citada puede ser ejecutada, bien en la memoria de lectura - escritura, o en caso contrario, en la memoria viva del sistema portable, cuando esta última presenta una capacidad suficiente. La etapa de lectura del código objeto y de memorización temporal de este último en la memoria de lectura - escritura está designada por carga del código de aplicación en la figura 2.

La etapa anteriormente citada va seguida entonces de una etapa (102) que consiste en someter el conjunto del código objeto memorizado temporalmente a un proceso de verificación, instrucción por instrucción, del código objeto anteriormente citado.

El proceso de verificación consiste al menos en una etapa de inicialización de la pila de los tipos y de la tabla de los tipos de datos que representan el estado de la máquina virtual al principio de la ejecución del código objeto memorizado temporalmente, así como en una sucesión de etapas de verificación, instrucción por instrucción por discriminación de la existencia, para cada instrucción corriente, anotado con (I_{i}), de un objetivo tal como un objetivo de instrucción de conexión anotado con (CIB), un objetivo de llamada de un gestor de excepciones o un objetivo de sub-rutina. Se lleva a cabo una verificación y una actualización del efecto de instrucción corriente (I_{i}) en la pila de los tipos y en la tabla de los tipos de registros.

Cuando la verificación se ha logrado en la etapa (103a), el protocolo objeto de la presente invención consiste en registrar en la etapa (104) el fragmento de programa descargado en un repertorio de fragmentos de programas disponibles y enviar a la etapa (105) del lector un acuse de recibo positivo.

Por lo contrario, en el caso de una comprobación no lograda del código objeto en la etapa (103b), el protocolo objeto de la invención consiste en inhibir, en una etapa (103c), toda ejecución, en el sistema portable del fragmento de programa registrado de momento. La etapa de inhibición (103c) puede ser puesta en práctica de unos modos diferentes. Esta etapa puede, a título de ejemplo no limitativo, consistir en borrar en la etapa (106) el fragmento de programa registrado de momento en ausencia de registro de este fragmento de programa en el repertorio de fragmentos de programas disponibles y, en una etapa (107), dirigir al lector un código de error. Las etapas (107 y 105) pueden ser llevadas a cabo bien secuencialmente después de las etapas (106) y respectivamente (104), o en una operación de tarea múltiple con éstas.

Con referencia a la misma figura 2, con una respuesta negativa en la etapa que consiste en detectar un comando de descarga en la etapa (100b), el protocolo objeto de la presente invención consiste en detectar, en una etapa (108), un comando de selección de un fragmento de programa disponible en un repertorio de fragmentos de programas y, con una respuesta positiva en la etapa (108), detectar la selección de un fragmento de programa disponible, y pedir a la etapa (109) este fragmento de programa disponible seleccionado con vistas a su ejecución. La etapa (109) es entonces seguida por una etapa de ejecución (110) del fragmento de programa disponible pedido por medio de la máquina virtual en ausencia de toda comprobación dinámica de tipos de variables, de los derechos de acceso a los objetos manipulados por el fragmento de programa disponible pedido o del desbordamiento de la pila de ejecución durante la ejecución de cada instrucción.

En el caso en que se obtiene una respuesta negativa en la etapa (108), esta etapa consiste en detectar un comando de selección de un fragmento de programa disponible pedido, el protocolo objeto de la presente invención consiste en proceder, en una etapa (111), al tratamiento de los comandos standard del sistema portable.

En lo que concierne a la ausencia de comprobación dinámica de tipo o de derecho de acceso a los objetos de tipo JavaCard por ejemplo, se indica que esta ausencia de comprobación no compromete la seguridad de la tarjeta porque el código de la aplicación ha pasado necesariamente la verificación con éxito.

De un modo más específico, se indica que la verificación de código llevada a cabo, conforme al procedimiento objeto de la invención, en la tarjeta con microprocesador o en el sistema informático portable es más selectiva que la comprobación habitual de códigos para la máquina virtual Java del modo que está descrito en la obra titulada "The Java Virtual Machine Specification" anteriormente mencionada en la descripción.

Sin embargo, todo código de la máquina virtual Java correcto en el sentido del verificador Java tradicional puede ser transformado en un código equivalente susceptible de pasar con éxito la verificación de código llevada a cabo en la tarjeta con microprocesador.

Mientras que es posible prever la escritura directa de códigos Java que satisfacen a los criterios de verificación anteriormente mencionados en el marco de la puesta en práctica del protocolo objeto de la presente invención, un objeto notable de ésta es igualmente la puesta en practica de un procedimiento de transformación automática de todo código Java standard en un código normalizado para el mismo fragmento de programa que satisface necesariamente a los criterios de verificación puestos en práctica anteriormente citados. El procedimiento de transformación en código normalizado y el sistema correspondiente se describirán ulteriormente en la descripción de modo detallado.

Una descripción más detallada del procedimiento de verificación de un fragmento de programa o aplicación, conforme al objeto de la presente invención, se dará ahora en relación con la figura (3a) y las figuras siguientes.

De un modo general, se indica que el procedimiento de comprobación objeto de la presente invención puede ser puesto en práctica o bien en el marco del protocolo de gestión de un fragmento de programa objeto de la invención anteriormente descrito en relación con la figura 2, o de modo independiente, con el fin de asegurar todo proceso de verificación juzgado necesario.

De un modo general, se indica que un fragmento de programa está constituido por un código objeto que consta al menos de un sub-programa, más comúnmente designado por método, y constituido por una secuencia de instrucciones ejecutables por el microprocesador del sistema portable por medio de la máquina virtual.

Del modo representado en la figura 3a, el procedimiento de comprobación consiste, para cada sub-programa, en llevar a cabo una etapa (200) de inicialización de la pila de los tipos y de la tabla de los tipos de registros de la máquina virtual por unos datos que representan el estado de esta máquina virtual al principio de la ejecución del código objeto, objeto de la verificación. Este código objeto puede ser memorizado temporalmente del modo descrito anteriormente en relación con la puesta en práctica del protocolo objeto de la presente invención.

La etapa (200) anteriormente citada es entonces seguida por una etapa (200a) que consiste en posicionar la lectura de la instrucción corriente (I_{i}), índice i, en la primera instrucción del código objeto. La etapa (200a) es seguida por una etapa (201) que consiste en llevar a cabo una verificación del código objeto anteriormente citado, instrucción por instrucción, por discriminación para cada instrucción corriente con referencia (I_{i}) de la existencia de un objetivo de instrucción de conexión (CIB), de un objetivo de llamada de gestor de excepciones, con referencia (CEM), o de un objetivo de una llamada de sub-rutina (CSR).

La etapa de verificación (201) es seguida por una etapa de verificación (202) de actualización del efecto de la instrucción corriente (I_{i}) en los tipos de datos de la pila de los tipos y de la tabla de los tipos de registros en función de la existencia, para la instrucción corriente indicada por otra instrucción, de un objetivo de instrucción de conexión (CIB), de un objetivo de una llamada de sub-rutina (CSR) o de un objetivo de una llamada de gestor de excepciones (CEM).

La etapa (202) para la instrucción corriente I_{i} es seguida de una etapa de prueba (203) de alcance de la última instrucción, prueba con referencia

I_{i} = última instrucción del código objeto?

Con una respuesta negativa en la prueba (203), el proceso pasa a la instrucción siguiente (204), con referencia i = i+1, y retorna a la etapa (201).

Se indica que la verificación anteriormente citada, en la etapa (202), se ha logrado cuando la tabla de los tipos de registros no se modifica en el transcurso de una verificación de todas las instrucciones (I_{i}) que constituyen el código objeto. En este objetivo, una prueba (205) de existencia de un estado estable de la tabla de los tipos de registros está previsto. Esta prueba tiene referencia:

3? estado estable de la tabla de los tipos de registro.

Con una respuesta positiva en la prueba (205), se ha logrado la verificación.

En el caso en que por lo contrario no se constata ninguna ausencia de modificación, el proceso de verificación se repite y se relanza por retorno a la etapa (200a). Se demuestra que el final del proceso está garantizado después de al menos Nr x H iteraciones donde (Nr) designa la cantidad de registros utilizados y (H) una constante que depende de la relación de sub-tipo.

Diferentes indicaciones en relación con los tipos de variables manipuladas en el transcurso del proceso de verificación descrito anteriormente en relación con la figura 3a se darán ahora en relación con la figura 3b.

Los tipos de variables anteriormente citadas constan al menos de los identificadores de clases correspondientes a las clases de objetos definidos en el fragmento de programa sometido a la verificación, de los tipos de variables numéricas que constan al menos de un tipo short, entero codificado en p bits, p puede tomar el valor de p = 16, y un tipo de dirección de retorno de una instrucción de salto (JSR), este tipo de dirección lleva referencia retaddr, un tipo null en relación con unas referencias de objetos nulos, un tipo object en relación con los objetos propiamente dichos, un tipo específico \bot que representa la intersección de todos los tipos y que corresponde con el valor cero nul, otro tipo específico T que representa la unión de todos los tipos y que corresponde con todo tipo de valores.

Con referencia a la figura 3b, se indica que el conjunto de los tipos de variables anteriormente citadas verifican una relación de sub-tipos:

object\gamma T;

short,retaddr\gamma T

\bot\gammanull, short, retaddr

Un ejemplo más específico de un proceso de verificación tal como el ilustrado en la figura 3a se dará ahora en unión con un primer ejemplo de estructura de datos ilustrado en la tabla T1 adjunta en anexo.

El ejemplo anteriormente citado se refiere a una aplicación escrita en código Java.

El proceso de verificación accede al código del sub-programa que constituye la aplicación sometida a comprobación por medio de un puntero en la instrucción (I_{i}) que se está verificando.

El proceso de verificación registra el tamaño y el tipo de la pila de ejecución al nivel de la instrucción corriente (I_{i}) correspondiente a (saload) en el ejemplo de la tabla T1 anteriormente mencionada.

El proceso de verificación registra entonces el tamaño y el tipo de pila de ejecución al nivel de la instrucción corriente en la pila de los tipos por medio de su puntero de pila de los tipos.

De la forma mencionada anteriormente en la descripción, esta pila de tipos refleja el estado de la pila de ejecución de la máquina virtual al nivel de la instrucción corriente (I_{i}). En el ejemplo representado en la tabla T1, durante la ejecución futura de la instrucción (I_{i}), la pila contendrá tres entradas: una referencia hacia un objeto de la clase (C), una referencia hacia una tabla de enteros codificados en p = 16 bits, el tipo short[], y un entero de p = 16 bits de tipo short. Esto está igualmente representado en la pila de los tipos que contiene también tres entradas: (C), el tipo de objetos de la clase (C), short[], el tipo de las tablas de enteros p = 16 bits y short, el tipo de enteros p = 16 bits.

Otra estructura de datos notable está constituida por una tabla de tipos de registros, esta tabla refleja el estado de los registros, es decir unos registros que memorizan las variables locales, de la máquina virtual.

Continuando con el ejemplo indicado en la tabla T1, se indica que la entrada (0) de la tabla de los tipos de registros contiene el tipo (C), es decir que durante la ejecución futura de la instrucción corriente I_{i} = (saload), está asegurado que el registro (0) contiene una referencia hacia un objeto de la clase (C).

Los diferentes tipos manipulados en el transcurso de la verificación y almacenados en la tabla de tipos de registros y en la pila de tipos están representados en la figura 3b. Estos tipos constan de:

-

unos identificadores de la clase CB correspondientes a las clases de objetos especificados definidos en la aplicación;

-

unos tipos de base, tales como short entero codificado en p = 16 bits, int1 e int2, p bits los más y los menos significativos respectivamente de enteros codificados en 2 p bits por ejemplo, o retaddr dirección de retorno de una instrucción, del modo mencionado anteriormente;

-

el tipo null que representa las referencias de objetos nulos.

En lo que se refiere a la relación de sub-tipos, se indica que un tipo (T1) es sub-tipo de un tipo (T2) si todo el valor válido del tipo (T1) es igualmente un valor válido del tipo (T2). Los sub-tipos entre identificador de clases reflejan la jerarquía de herencia entre clases de la aplicación. En los otros tipos, el sub-tipo está definido por el enrejado representado en la figura 3b, siendo \bot sub-tipo de todos los tipos y todos los tipos son sub-tipos de (T).

El desarrollo del proceso de verificación de un sub-programa que constituye una aplicación es el siguiente, con referencia a la tabla T1 anteriormente mencionada.

El proceso de verificación se lleva a cabo de modo independiente en cada sub-programa de la aplicación. Para cada sub-programa, el proceso lleva a cabo uno o varios pasos de verificación en las instrucciones del sub-programa considerado. El seudo-código del proceso de verificación se da en la tabla T2 adjunta en anexo.

El proceso de comprobación de un sub-programa empieza por la inicialización de la pila de los tipos y de la tabla de los tipos de registros representados en la tabla T1, esta inicialización refleja el estado de la máquina virtual al principio de la ejecución del sub-programa examinado.

La pila de los tipos está vacía inicialmente, el puntero de pila es igual a cero, y los tipos de registros se inicializan con los tipos de los parámetros del sub-programa que ilustran el hecho de que la máquina virtual pasa los parámetros de este sub-programa en estos registros. Los tipos de registros permitidos por el sub-programa se inicializan en los tipos de datos \bot que ilustran el hecho de que la máquina virtual inicializa estos registros a cero al principio de la ejecución del sub-programa.

A continuación, se llevan a cabo uno o varios pasos de verificación en las instrucciones y en cada instrucción corriente (I_{i}) del sub-programa.

Al final del paso de verificación puesto en práctica o de una sucesión de pasos por ejemplo, el proceso de verificación determina si los tipos de registros contenidos en la tabla de los tipos de registros representados en la tabla T1 del anexo han cambiado durante el paso de verificación. Con la ausencia de cambio, la verificación se termina y un código de éxito se reenvía al programa principal, el cual permite enviar el acuse de recibo positivo a la etapa (105) del protocolo de gestión representado en la figura 2.

En presencia de una modificación de la tabla de los tipos de registros anteriormente citada, el proceso de verificación reitera el paso de comprobación hasta que los tipos de registros contenidos en la tabla de los tipos de registros estén estables.

El desarrollo propiamente dicho de un paso de verificación llevado a cabo una o varias veces hasta la estabilidad de la tabla de los tipos de registros se describirá ahora en relación con las figuras 3c hasta 3j.

Para cada instrucción corriente (I_{i}), se llevan a cabo las verificaciones siguientes:

En relación con la figura 3a en la etapa (201), el proceso de verificación determina si la instrucción corriente (I_{i}) es el objetivo de una instrucción de conexión, de llamada de sub-rutina o de un gestor de excepción, del modo mencionado anteriormente. Esta comprobación se lleva a cabo por examen de las instrucciones de conexión contenidas en el código del sub-programa y de los gestores de excepciones asociados a este sub-programa.

Con referencia a la figura 3c abierta por la etapa (201), cuando la instrucción corriente (I_{i}) es el objetivo de una instrucción de conexión, esta condición se lleva a cabo por una prueba (300) designado por I_{i} = CIB, esta conexión es incondicional o condicional, el proceso de verificación asegura que la pila de los tipos está vacía en este punto del sub-programa por una prueba (301). Con una respuesta positiva a la prueba (301), el proceso de comprobación continua por una etapa secuencia de contexto con referencia secuencia (A). Con una respuesta negativa a la prueba (301), la pila de los tipos no está vacía, la verificación falla y la aplicación es rechazada. Este fallo se representa por la etapa (Echec).

Con referencia a la figura 3d abierta por la etapa secuencia (A), cuando la instrucción (I_{i}) es el objetivo de una llamada de sub-rutina, esta condición se lleva a cabo por una prueba (304) I_{i} = CSR, el proceso de verificación comprueba en una prueba (305) que la instrucción precedente (I_{i-1}) no continua en secuencia. Esta verificación se lleva a cabo por una etapa de prueba (305) cuando la instrucción precedente constituye una conexión incondicional, un retorno de sub-rutina o una llamada de excepción. La prueba en la etapa (305) se anota de la siguiente forma:

I_{i-1} = IB_{incondicional}, retorno RSR o llamada L-EXCEPT.

Con una respuesta negativa en la prueba (305), el proceso de verificación falla en una etapa (Echec). Por lo contrario, con una respuesta positiva a la prueba (305), el proceso de comprobación reinicializa la pila de los tipos de modo que ésta contenga exactamente una entrada de tipo retaddr, dirección de retorno de la sub-rutina mencionada anteriormente. Si la instrucción corriente (I_{i}) en la etapa (304) no es el objetivo de una llamada de sub-rutina, el proceso de verificación continua en el contexto en la etapa secuencia (B).

Con referencia a la figura 3e, cuando la instrucción corriente (I_{i}) es el objetivo de un gestor de excepciones, esta condición se lleva a cabo por una prueba (307) con referencia I_{i}= CEM, CEM designa el objetivo de un gestor de excepciones, esta condición se lleva a cabo por medio de una prueba (307), con referencia:

I_{i} = CEM.

El proceso, con una respuesta positiva a la prueba (307) verifica que la instrucción precedente constituye una ramificación incondicional, un retorno de sub-rutina o una llamada de excepciones por medio de una prueba (305) con referencia:

I_{i-1} = IB_{incondicional}, retorno RSR o llamada L-EXCEPT.

Con una respuesta positiva en la prueba (305), el proceso de comprobación procede a una reactualización de la pila de los tipos, en una etapa (308), por una entrada de tipos de las excepciones, con referencia tipo EXCEPT, la etapa (308) es seguida por con una etapa de secuencia de contexto, secuencia (C). Con una respuesta negativa a la prueba (305), el proceso de verificación falla por la etapa marcada (Echec). El fragmento de programa se rechaza entonces.

Con referencia a la figura 3f, cuando la instrucción corriente (I_{i}) es el objetivo de una pluralidad de conexiones incompatibles, esta condición se lleva a cabo por una prueba (309), que lleva referencia:

I_{i} = XIB incompatibles

las conexiones incompatibles son por ejemplo una conexión incondicional y una llamada de sub-rutina o aún dos gestores de excepciones diferentes. Con una respuesta positiva a la prueba (309), siendo las conexiones incompatibles, el proceso de comprobación falla por una etapa con referencia (Echec) y el fragmento de programa es rechazado. Con una respuesta negativa a la prueba (309), el proceso de verificación continua con una etapa de referencia secuencia (D). La prueba (309) se abre por la etapa secuencia (C) anteriormente mencionada en la descripción.

Con referencia a la figura 3g, cuando la instrucción corriente (I_{i}) no es el objetivo de ninguna conexión, esta condición se lleva a cabo por una prueba (310) abierta por la secuencia (D) anteriormente mencionada, esta prueba tiene referencia

I_{i} \phi? objetivos de conexión,

\phi designa el símbolo de existencia,

el proceso de verificación continua con respuesta negativa en la prueba (310) por el paso a una actualización de la pila de los tipos en una etapa (311), la etapa (311) y la respuesta positiva a la prueba (310) son seguidas por una etapa de secuencia de contexto en la etapa (202), descrita anteriormente en la descripción en relación con la figura 3a.

Una descripción más detallada de la etapa de verificación del efecto de la instrucción corriente en la pila de los tipos en la etapa (202) anteriormente mencionada se dará ahora en relación con la figura 3h.

De acuerdo con la figura anteriormente mencionada, esta etapa puede constar al menos de una etapa (400) de verificación que la pila de ejecución de los tipos contiene al menos tantas entradas como la instrucción corriente consta de operandos. Esta etapa de prueba (400) lleva la referencia:

Nbep \geq NOpi

donde (Nbep) designa la cantidad de entradas de la pila de los tipos y (FOPI) designa la cantidad de operandos contenidos en la instrucción corriente. Con una respuesta positiva a la prueba (400), esta prueba va seguida de una etapa (401a) de desapilamiento de la pila de los tipos y de comprobación (401b) que los tipos de las entradas en la cumbre de la pila son sub-tipos de los tipos de los operandos de la instrucción corriente anteriormente mencionada. En la etapa de prueba (401a), los tipos de los operandos de la instrucción (i) se anotan (TOpi) y los tipos de las entradas en la cumbre de la pila llevan la referencia (Targs).

En la etapa (401b), la comprobación corresponde a una verificación de la relación de sub-tipos Targs sub-tipo de TOpi.

Con una respuesta negativa a la prueba (400) y a la prueba (401b), el proceso de comprobación falla, lo que se ilustra por el acceso a la etapa (Echec). Por lo contrario, con una respuesta positiva a la prueba (401b), el proceso de verificación es continuado y consiste en llevar a cabo:

-

una etapa de comprobación de la existencia de un espacio de memoria suficiente en la pila de los tipos, para proceder al apilamiento de los resultados de la instrucción corriente. Esta etapa de comprobación se lleva a cabo por una prueba (402), con referencia:

Esp-pila \geq Esp-resultado.

donde cada miembro de desigualdad designa el espacio memoria correspondiente. Con una respuesta negativa a la prueba (402), el proceso de comprobación falla, lo que se ilustra por la etapa (Echec). Por lo contrario, con una respuesta positiva a la prueba (402), el proceso de verificación procede entonces al apilamiento de los tipos de datos atribuidos a los resultados en una etapa (403), el apilamiento se lleva a cabo en la pila de los tipos de datos atribuida a estos resultados.

A título de ejemplo no limitativo, se indica que para la puesta en práctica de la figura 3h de comprobación del efecto de la instrucción corriente sobre la pila de los tipos, para una instrucción corriente constituida por una instrucción Java saload correspondiente a la lectura de un elemento entero codificado en P = 16 bits en una tabla de enteros, esta tabla de enteros está definido por la tabla de enteros y un índice entero en esta tabla, y el resultado por el entero leído en este índice en esta tabla, el proceso de verificación asegura que la pila de los tipos contiene al menos dos elementos, que los dos elementos en la cumbre de la pila de los tipos son sub-tipos de short[] respectivamente short, procede al proceso de desapilamiento y a continuación al proceso de apilamiento del tipo de datos short como tipo del
resultado.

Además, con referencia a la figura 3i, para la puesta en práctica de la etapa de comprobación del efecto de la instrucción corriente sobre la pila de los tipos, cuando la instrucción corriente (I_{i}) es una instrucción de lectura, con referencia (IR), de un registro de dirección (n), esta condición se lleva a cabo por una prueba (404) de referencia I_{i} = IR_{n}, con una respuesta positiva a la prueba (404) anteriormente mencionada, el proceso de verificación consiste en comprobar el tipo de datos del resultado de esta lectura, en una etapa (405), por consulta de la entrada (n) de la tabla de los tipos de registros, para luego determinar el efecto de la instrucción corriente (I_{i}) sobre la pila de los tipos por una operación (406a) de desapilamiento de las entradas de la pila correspondiente a los operandos de esta instrucción corriente y por apilamiento (406b) del tipo de datos de este resultado. Los operandos de la instrucción (I_{i}) llevan la referencia (OP_{i}). Las etapas (406a y 406b) van seguidas de un retorno a la secuencia de contexto secuencia (F). Con una respuesta negativa a la prueba (404), el proceso de verificación continua con la secuencia de contexto
secuencia (F).

Con referencia a la figura 3j, cuando la instrucción corriente (I_{i}) es una instrucción de escritura, con referencia (IW), de un registro de dirección (n), esta condición se lleva a cabo por una prueba con referencia I_{i} = IW_{m}, el proceso de verificación consiste, con una respuesta positiva a la prueba (407), en determinar en una etapa (408) el efecto de la instrucción corriente sobre la pila de los tipos y el tipo (t) del operando escrito en el registro de dirección (n), luego, en una etapa (409), a sustituir la entrada del tipo de la tabla de los tipos de registros a la dirección (n) por el tipo inmediatamente superior al tipo anteriormente almacenado y al tipo (t) del operando escrito en el registro de dirección (n). La etapa (409) es seguida por un retorno a la secuencia de contexto serie (204). Con una respuesta negativa a la prueba (407), el proceso de verificación es seguido por una secuencia de contexto secuencia (204).

A título de ejemplo, cuando la instrucción corriente (I_{i}) corresponde a la escritura de un valor de tipo (D) en un registro de dirección (1) y que el tipo del registro (1) antes de la verificación de la instrucción era (C), el tipo del registro (1) es sustituido por el tipo objeto que es el tipo superior más pequeño de (C y D) en el enrejado de los tipos representado en la figura 3b.

De la misma forma, a título de ejemplo, cuando la instrucción corriente (I_{i}) es una lectura de una instrucción (aload-0) que consiste en apilar el contenido del registro (0) y que la entrada (0) de la tabla de los tipos de registros es (C), el verificador apila (C) sobre la pila de los tipos.

Un ejemplo de verificación de un sub-programa escrito en entorno Java se dará ahora en relación con las tablas T3 y T4 introducidas en anexo.

La tabla T3 representa un código JavaCard específico correspondiente al sub-programa Java incluido en esta tabla.

La tabla T4 ilustra el contenido de la tabla de los tipos de registros y de la pila de los tipos antes de la verificación de cada instrucción. Las restricciones de tipos sobre los operandos de las diferentes instrucciones se respetan todas. La pila está vacía tanto después de la instrucción de conexión (5) - en la instrucción (9) simbolizada por la flecha, como antes del objetivo de conexión (9) anteriormente citado. El tipo de registro (1) que era inicialmente \bot se convierte en null, el borne superior de null y de \bot, durante la instrucción (1) de almacenaje de un valor de tipo null en el registro (1) se examina, luego se convierte en tipo short[], el borne superior del tipo short[] y del tipo null, cuando se trata la instrucción (8), de almacenaje de un valor de tipo short[] en el registro (1). El tipo del registro (1) que ha cambiado durante el primer paso de verificación, un segundo paso se lleva a cabo partiendo de nuevo de los tipos de registros obtenidos al final de la primera. Este segundo paso de verificación se logra al igual que el primero y no modifica los tipos de los registros. El proceso de verificación se termina por tanto con éxito.

Diferentes ejemplos de casos de fallo del proceso de verificación en cuatro ejemplos de código incorrecto se darán ahora en relación con la tabla T5 introducida en anexo:

-

En el punto a) de la tabla T5, el código dado como ejemplo tiene por objeto intentar fabricar una referencia de objeto inválido al utilizar un proceso aritmético en los punteros. Es rechazado por la verificación de los tipos de los argumentos de la instrucción (2 sadd), que exige que estos dos argumentos sean de tipo short.

-

En los puntos b) y c) de la tabla T5, el código tiene por objeto llevar a cabo dos intentos de convertir un entero cualquiera en una referencia de objeto. En el punto b), el registro (0) se usa a la vez con el tipo short, instrucción (0) y con el tipo null, instrucción (5). En consecuencia, el proceso de verificación atribuye el tipo T al registro (0) y detecta un error de tipo cuando el registro (0) es re-enviado como resultado de tipo objeto a la instrucción (7).

-

En el punto c) de la tabla T5, un conjunto de conexiones del tipo "if ... then ... else ..." se usa para dejar en la cumbre de la pila un resultado que está constituido bien por un entero o por una referencia de objeto. El proceso de verificación rechaza este código porque detecta que la pila no está vacía al nivel de la conexión de la instrucción (5) hacia la instrucción (9) simbolizada por la flecha.

-

Finalmente, en el punto d) de la tabla T5, el código contiene un lazo que, en cada iteración, tiene como efecto apilar un entero más en la cumbre de la pila y provocar por tanto un desbordamiento de la pila después de una cierta cantidad de iteraciones. El proceso de verificación rechaza este código al constatar que la pila no está vacía al nivel de la conexión trasera de la instrucción (8) hacia la instrucción (0), simbolizado por la flecha de retorno, al no estar vacía la pila en un punto de conexión.

Los diferentes ejemplos dados anteriormente en relación con las tablas T3, T4 y T5 muestran que el proceso de verificación, objeto de la presente invención, es particularmente eficaz y que se aplica a unas aplicaciones y en particular a los sub-programas de estas últimas, para las cuales las condiciones de tipo de pila respectivamente de carácter vacío de la pila de los tipos anteriores y las instrucciones de conexión o de objetivos de conexión se satisfacen.

Está claro que tal proceso de comprobación implica la escritura de códigos objeto que satisfacen a estos criterios, estos códigos objeto pueden corresponder al sub-programa introducido en la tabla T3 anteriormente mencionado.

Sin embargo, y con el fin de asegurar la verificación de aplicaciones y de sub-programas de aplicaciones existentes que no satisfacen necesariamente los criterios de verificación del procedimiento objeto de la presente invención, en particular en lo que se refiere a las aplicaciones y los sub-programas escritos en entorno Java, la presente invención tiene por objeto establecer unos procedimientos de transformación de estas aplicaciones o sub-programas en aplicaciones o fragmentos de programa normalizados que permiten sufrir con éxito las pruebas de verificación del procedimiento de verificación objeto de la presente invención y del protocolo de gestión, poniendo en práctica tal procedimiento.

En este objetivo, la invención tiene por tanto por objeto la puesta en práctica de un procedimiento y de un programa de transformación de un código objeto clásico que constituye una aplicación, este procedimiento y este programa de transformación pueden ser puestos en práctica fuera de un sistema portable o de una tarjeta con microprocesador durante la creación de la aplicación en consideración.

El procedimiento de transformación de código en código normalizado objeto de la presente invención, se describirá ahora en el marco del entorno Java a título de ejemplo puramente ilustrativo.

Los códigos (JVM) producidos por los compiladores Java existentes satisfacen a diferentes criterios, que se enuncian a continuación:

C1:

los argumentos de cada instrucción pertenecen a los tipos esperados por esta instrucción;

C2:

la pila no se desborda;

C'3:

para cada instrucción de conexión, el tipo de la pila al nivel de esta conexión es el mismo que en el nivel de los objetivos posibles para esta conexión;

C'4:

un valor de tipo t escrito en un registro en un punto del código y releído desde este mismo registro en otro punto del código siempre se vuelve a leer con el mismo tipo t;

La puesta en práctica del procedimiento de verificación objeto de la presente invención, implica que los criterios (C'3 y C'4) comprobados por el código objeto sometidos a verificación sean sustituidos por los criterios (C3 y C4) seguidamente indicados:

C3:

la pila está vacía en cada instrucción de conexión y en cada objetivo de conexión;

C4:

un mismo registro se usa con un solo y mismo tipo en todo el código de un sub-programa.

Con referencia a los criterios anteriormente citados, se indica que los compiladores Java garantizan solo los criterios más débiles (C'3 y C'4), el proceso de verificación objeto de la presente invención y el protocolo de gestión correspondiente garantizan de hecho unos criterios (C3 y C4) más restringentes que permiten asegurar la seguridad de ejecución y de gestión de las aplicaciones.

La noción de normalización que recubre la transformación de los códigos en códigos normalizados puede presentar diferentes aspectos, en la medida en que la sustitución de los criterios (C'3 y c'4) por los criterios (C3 y C4), conforme al proceso de verificación objeto de la presente invención, puede ser llevada a cabo de modo independiente para asegurar que la pila está vacía en cada instrucción de conexión y en cada objetivo de conexión, respectivamente que los registros abiertos por la aplicación son tipificados, en cada registro abierto le corresponde un solo tipo de dato atribuido para la ejecución de la aplicación considerada, o por lo contrario, de modo conjunto, con el fin de satisfacer al conjunto del proceso de verificación objeto de la presente invención.

El procedimiento de transformación de un código objeto en un código objeto normalizado de acuerdo con la invención se describirá en consecuencia de acuerdo con dos modos de puesta en práctica diferentes, un primer modo de puesta en práctica correspondiente con la transformación de un código objeto que satisface a los criterios (C1, C2, C'3, C'4) en un código normalizado que satisface a Los criterios (C1, C2, C3, C'4) correspondiente con un código normalizado de instrucción de conexión u objetivo de conexión vacío, luego de acuerdo con un segundo modo de realización, en el cual el código objeto clásico que satisface a los mismos criterios de partida, es transformado en un código normalizado que satisface a los criterios (C1, C2, C'3,C4) por ejemplo correspondiente con un código normalizado que recurre a unos registros tipificados.

El primer modo de realización del procedimiento de transformación de código, objeto de la presente invención, se describirá ahora en relación con la figura 4a. En el modo de realización ilustrado en la figura 4a, el código clásico de partida está reputado de satisfacer a los criterios (C1 + C2 + C'3) y el código normalizado obtenido por el hecho de la transformación está reputado de satisfacer a los criterios (C1 + C2 + C3).

De acuerdo con la figura anteriormente citada, el procedimiento de transformación consiste, para cada instrucción corriente (I_{i}) del código o del sub-programa, en anotar cada instrucción, en una etapa (500), por el tipo de datos de la pila antes y después de la ejecución de esta instrucción. Los datos de anotación se observan (AI_{i}) y están asociados por la relación I_{i} 76 AI_{i} en instrucción corriente considerada. Los datos de anotación se calculan por medio de un análisis del flujo de los datos en relación con esta instrucción. Los tipos de datos antes y después de la ejecución de la instrucción llevan la referencia (tbe_{i} y tae_{i}) respectivamente. El cálculo de los datos de anotación por análisis del flujo de datos es un cálculo clásico conocido por el hombre del oficio y, a este título, no se describirá en detalle.

La operación llevada a cabo en la etapa (500) se ilustra en la tabla T6 adjuntado en anexo en el cual para una aplicación o sub-programa de aplicación que consta de 12 instrucciones, se introducen los datos de anotación (AI_{i}) constituidos por los tipos de los registros y los tipos de la pila.

La etapa (500) anteriormente citada es entonces seguida por una etapa (500a) que consiste en posicionar el índice i en la primera instrucción I_{i} = I_{1}. La etapa (500a) es seguida por una etapa (501) que consiste en detectar, en el seno de las instrucciones y de cada instrucción corriente (I_{i}), la existencia de conexiones con referencia (IB) o de objetivos de conexión (CIB) para los cuales la pila de ejecución no está vacía. Esta detección (501) es llevado a cabo por una prueba llevada a cabo a partir de los datos de anotación (AI_{i}) del tipo de las variables de pila asignadas a cada instrucción corriente, la prueba se anota para la instrucción corriente:

I_{i} es un IB o CIB y pila (AI)\neq vacío.

En una respuesta positiva a la prueba (501), es decir en la presencia de una detección de una pila de ejecución no vacía, la prueba anteriormente mencionada es seguida por una etapa que consiste en insertar unas instrucciones de transferencia de los variables de pila por una y otra parte de estas conexiones (IB) o de estos objetivos de conexión (CIB), con el fin de vaciar el contenido de la pila de ejecución en unos registros temporales antes de esta conexión y de restablecer la pila de ejecución a partir de los registros temporales después de esta conexión. La etapa de inserción lleva la referencia (502) en la figura 4a. Es seguida por una etapa de prueba (503) de alcance de la última instrucción de referencia

I_{i} = última instrucción?

Con una respuesta negativa a la prueba (503), un incremento (504) i = i+1 se lleva a cabo para el paso a la instrucción siguiente y retorno a la etapa (501). Con una respuesta positiva a la prueba (503), se lanza una etapa de Fin. Con una respuesta negativa a la prueba (501), el procedimiento de transformación es seguido por una conexión hacia la etapa (503) en ausencia de inserción de instrucción de transferencia. La puesta en práctica del procedimiento de transformación de un código clásico en un código normalizado con instrucción de conexión a una pila vacía del modo representado en la figura 4a, permite obtener un código objeto normalizado para el mismo fragmento de programa de partida en el cual la pila de las variables de pila está vacía en cada instrucción de conexión y en cada instrucción de objetivo de conexión, en la ausencia de modificación de la ejecución del fragmento de programa. En el caso de un entorno Java, las instrucciones de transferencia de datos entre pila y registro son las instrucciones load y store de la máquina virtual Java.

Al volver a tomar el ejemplo introducido en la tabla T6, el procedimiento de transformación detecta un objetivo de conexión donde la pila no está vacía al nivel de la instrucción (9). Por tanto se procede con la inserción de una instrucción istore 1 antes de la instrucción de conexión (5) que lleva a la instrucción (9) anteriormente mencionada con el fin de salvar el contenido de la pila en el registro (1) y de asegurar que la pila está vacía durante la conexión. Simétricamente, la inserción de una instrucción iload 1 se lleva a cabo antes del objetivo de instrucción (9) para restablecer el contenido de la pila de modo idéntico a lo que era antes de la conexión. Finalmente, una instrucción istore 1 se inserta después de la instrucción (8) para garantizar el equilibrio de la pila en los dos caminos que llevan a la instrucción (9). El resultado de la transformación operada de esta forma en un código normalizado está representado en la tabla T7.

El segundo modo de realización del procedimiento de transformación objeto de la presente invención se describirá ahora en relación con la figura 4b en el caso en que el código objeto clásico de partida satisface a los criterios (C1 + C'4) y el código objeto normalizado satisface a los criterios (C1 + C4).

Con referencia a la figura 4b anteriormente citado, se indica que el procedimiento, en este modo de realización, consiste en anotar, de acuerdo con una etapa (500) sensiblemente idéntica a la representada en la figura 4a, cada instrucción corriente (I_{i}) por el tipo de datos de los registros antes y después de la ejecución de esta instrucción. De la misma forma, los datos de anotación (AI_{i}) se calculan por medio de un análisis del flujo de datos en relación con esta instrucción.

La etapa de anotación (500) es entonces seguida por una etapa que consiste en llevar a cabo una nueva asignación de los registros, etapa con referencia (601), por detección de los registros de origen empleados con unos tipos diferentes, división de estos registros de origen en registros normalizados diferentes, un registro normalizado está asignado a cada tipo de datos utilizado. La etapa (601) es seguida por una etapa (602) de reactualización de las instrucciones que manipulan los operandos que hacen uso de los registros normalizados anteriormente mencionados. La etapa (602) es seguida por una etapa de secuencia de contexto (302).

Con referencia al ejemplo dado en la tabla T6, se indica que el procedimiento de transformación detecta que el registro de gama (0), referencia (r0), se usa con los dos tipos objeto, instrucciones (0 y 1), e int, instrucción (9) y siguientes. Entonces se procede a una división del registro de origen (r0) en dos registros, el registro (0) para el uso de los tipos objeto y el registro (1) para los usos de tipo int. Las referencias en el registro (0) de tipo int se vuelven a escribir entonces al transformarlos en unas referencias a los registros (1), el código normalizado obtenido se introduce en la tabla T8 adjuntada en anexo.

Se observa de modo no limitativo que en el ejemplo introducido en relación con la tabla T8 anteriormente mencionada, el nuevo registro (1) se usa a la vez para la normalización de la pila como para la creación de registros tipificados por división del registro (0) en dos registros.

El procedimiento de transformación de un código clásico en un código normalizado con instrucción de conexión a pila vacía tal como se describe en la figura 4a se describirá ahora de modo más detallado en un modo de realización preferencial no limitativo, en relación con la figura 5a.

Este modo de realización se refiere a la etapa (501) que consiste en detectar en el seno de las instrucciones y de cada instrucción corriente (I_{i}) la existencia de conexión (IB) respectivamente de objetivo de conexión (CIB) para la cual la pila no está vacía.

Como continuación a la determinación de las instrucciones objetivo donde la pila no está vacía, esta condición se observa en la etapa (504a), I_{i} pila\neq vacío, el proceso de transformación consiste en asociar, en la etapa (504a) anteriormente mencionada, a estas instrucciones un conjunto de nuevos registros, uno por emplazamiento de pila activa al nivel de estas instrucciones. De esta forma, si (i) designa el rango de un objetivo de conexión cuyo tipo de pila asociada no está vacío y es del tipo (tpI_{i}) a (tpn_{i}) con n > 0, pila no vacía, el proceso de transformación asigna (n) nuevos registros, (r_{1}) a (r_{n}) aún no utilizados y los asocia a la instrucción (i) correspondiente. Esta operación se lleva a cabo en la etapa (504a).

La etapa (504a) es seguida por una etapa (504) que consiste en examinar cada instrucción detectada de rango (i) y discriminar en una etapa de prueba (504) la existencia de un objetivo de conexión (CIB) o de una conexión (IB). La etapa (504) está representada en forma de una prueba designada por:

\phi? CIB, IB e I_{i} = CIB.

En el caso en que la instrucción de rango (i) es un objetivo de conexión (CIB) representado por la igualdad precedente, y que la pila de las variables de pila al nivel de esta instrucción no está vacía, es decir con una respuesta positiva a la prueba (504), para toda instrucción precedente del rango (i-1) constituida por una conexión, una llamada de excepciones o un retorno de programa, esta condición se lleva a cabo en la etapa de prueba (505) designada por:

I_{i-1} = IB, llamada EXCEPT, retorno Prog.

La instrucción detectada de rango (i) solo es accesible por una conexión. Con una respuesta positiva a la prueba (505) anteriormente citada, el proceso de transformación consiste en llevar a cabo una etapa (506) que consiste en insertar un conjunto de instrucciones de carga del tipo load a partir del conjunto de nuevos registros anteriormente a la instrucción detectada del rango (i) considerada. La operación de inserción (506) es seguida por una redirección (507) de todas las conexiones hacia la instrucción detectada del rango (i), hacia la primera instrucción de carga load insertada. Las operaciones de inserción y de redirección están representadas en la tabla T9 adjuntada en anexo.

Para toda instrucción anterior del rango (i-1) que continua en secuencia, es decir cuando la instrucción corriente del rango (i) es accesible a la vez por una conexión y a partir de la instrucción precedente, esta condición se lleva a cabo por la prueba (508) y está simbolizada por las relaciones:

I_{i-1} 6 I_{i}

\hskip0,5cm

e

\hskip0,5cm

IB 6 I_{i}

el proceso de transformación consiste en una etapa (509) que inserta un conjunto de instrucciones de almacenaje store hacia el conjunto de nuevos registros anteriormente a la instrucción detectada de rango (i), y un conjunto de instrucciones de carga load a partir de este conjunto de nuevos registros. La etapa (509) es entonces seguida por una etapa (510) de redirección de todas las conexiones hacia la instrucción detectada de rango (i) hacia la primera instrucción de carga load insertada.

En el caso en que la instrucción detectada de rango (i) es una conexión hacia una instrucción determinada, para toda instrucción detectada de rango (i) constituida por una conexión incondicional, esta condición se lleva a cabo por una prueba (511) indicada:

I_{i} = IB_{incondit}

el proceso de transformación tal como está representado en la figura 5a consiste en insertar en una etapa (512), con una respuesta positiva a la prueba (511), anteriormente a la instrucción detectada de rango (i), una pluralidad de instrucciones de almacenaje store. El proceso de transformación inserta antes de la instrucción (i) las (n) instrucciones store del modo representado en el ejemplo en la tabla T11. Las instrucciones store dirigen los registros (r_{1} a r_{n}), donde (n) designa la cantidad de registros. En cada nuevo registro se asocia así la instrucción de almacenaje.

Para toda instrucción detectada de rango (i) constituida por una conexión condicional y para una cantidad (mOp) superior a (0) de operandos manipulados por esta instrucción de conexión condicional, esta condición se lleva a cabo por la prueba (513) de referencia:

I_{i} = IB_{condit}

con mOp > 0

el proceso de transformación, con una respuesta positiva a la prueba (513) anteriormente citada, consiste en insertar en una etapa (514) anteriormente a esta instrucción detectada de rango (i), una instrucción de permutación de referencia (swap_x) en la cumbre de la pila de las variables de pila de los (mOp) operandos de la instrucción detectada de rango (i) y de los (n) valores siguientes. Esta operación de permutación permite llevar a la cumbre de la pila de las variables de pila los (n) valores a salvar el conjunto de los nuevos registros (r_{1} a r_{n}). La etapa (514) es seguida por una etapa (515) que consiste en insertar anteriormente a la instrucción de rango (i) un conjunto de instrucciones de almacenaje store hacia el conjunto de los nuevos registros (r_{1} a r_{n}). La etapa (515) de inserción anteriormente mencionada es ella misma seguida por una etapa (516) de inserción posteriormente a la instrucción detectada de rango (i) de un conjunto de instrucciones de carga load a partir del conjunto de los nuevos registros (r_{1} a r_{n}). El conjunto de las operaciones de inserción correspondientes está representado en la tabla 12 introducida en anexo.

Por motivos de estar completo y con referencia a la figura 5a, se indica que, con una respuesta negativa a la prueba (504), la continuación del proceso de transformación se lleva a cabo por una etapa de secuencia de contexto, secuencia (503), que la respuesta negativa a las pruebas (505, 508, 511 y 513) es ella misma seguida por una continuación del proceso de transformación por medio de una etapa de secuencia de contexto, secuencia (503) y que es lo mismo en lo que se refiere a la continuación de las operaciones después de las etapas de redirección (507 y 510) y de inserción (512 y 516) anteriormente citadas.

Una descripción más detallada del procedimiento de normalización y de transformación de un código objeto en un código objeto normalizado que hace uso de unos registros tipificados del modo descrito en la figura 4b, se dará ahora en relación con la figura 5b. Este modo de realización se refiere más particularmente a un modo de realización preferencial no limitativo de la etapa (601) de nueva asignación de los registros por detección de los registros de origen empleados con unos tipos diferentes.

Con referencia a la figura 5b anteriormente citada, se indica que la etapa (601) anteriormente citada consiste en determinar en una etapa (603) los intervalos de duración, de referencia (ID_{j}) de cada registro (r_{j}). Estos intervalos de duración, designados por "live range" o "webs" en el idioma anglo-sajón, están definidos para un registro (r) como un conjunto máximo de trazas parciales, tal como el registro (r), es vivo en todos los puntos de estas trazas. Para una definición más detallada de estas anotaciones, se podrá útilmente referirse a la obra editada por Steven S. MUCHNICK titulada "Advanced Compiler Design and Implementation", Sección 16.3, Morgah KAUFMANN, 1997. La etapa 603 está representada por la relación:

ID_{j} 76 r_{j}

de acuerdo con la cual a cada registro (r_{j}) está asociado un intervalo de duración (ID_{j}) correspondiente.

La etapa (603) anteriormente citada es seguida por una etapa (604) que consiste en determinar, en la etapa (604), el tipo de datos principal, de referencia (tp_{j}), de cada intervalo de duración (ID_{j}). El tipo principal de un intervalo de duración (ID_{j}), para un registro (r_{j}), está definido por el borne superior de los tipos de datos almacenados en este registro (r_{j}) por las instrucciones de almacenaje store que pertenecen al intervalo de duración anteriormente citado.

La etapa (604) en sí es seguida por una etapa (605) que consiste en establecer un gráfico de interferencias entre los intervalos de duración anteriormente definidos en las etapas (603 y 604), este gráfico de interferencias consiste en un gráfico no orientado del cual cada cumbre está constituida por un intervalo de duración y cuyos arcos, con referencias (a_{j1j2}) en la figura 5b, entre dos cumbres (ID_{j1} e ID_{j2}), existen si una cumbre contiene una instrucción de almacenaje dirigida al registro de la otra cumbre o recíprocamente. En la figura 5b, la construcción del gráfico de interferencias está representada simbólicamente, esta construcción puede ser llevada a cabo a partir de técnicas de cálculo conocidas por el hombre del oficio. Para una descripción más detallada de la construcción de este tipo de gráfico, se podrá útilmente referirse a la obra publicada por Alfred V. AHO, Ravi SETHI y Jeffrey D. ULLMAN titulada "Compilers: principles, techniques, and tools", Addison-Wesley 1986, sección 9.7.

Como continuación a la etapa (605), el procedimiento de normalización del modo representado en la figura 5b consiste en traducir en una etapa (606) la unicidad de un tipo de dato asignado a cada registro (r_{i}) en el gráfico de interferencias al añadir unos arcos entre todos los pares de cumbres del gráfico de interferencias mientras que dos cumbres de un par de cumbres no tienen el mismo tipo de datos principal asociado. Se comprende que la traducción del carácter de unicidad de un tipo de dato asignado a cada registro corresponde, claro está, a la traducción y a la toma en cuenta del criterio (C4) en el gráfico de interferencias, criterio mencionado anteriormente en la descripción. La etapa (606) anteriormente citada es seguida entonces por una etapa (607) en la cual se lleva a cabo una instanciación del gráfico de interferencias, instanciación más comúnmente designada por etapa de coloreado del gráfico de interferencias de acuerdo con las técnicas habituales. En el transcurso de la etapa (607), el proceso de transformación atribuye a cada intervalo de duración (ID_{jk}) un número de registro (rk) de tal forma que dos intervalos adyacentes en el gráfico de interferencias reciben unos números de registros diferentes.

Esta operación se puede llevar a cabo a partir de todo proceso adaptado. A título de ejemplo no limitativo, se indica que un proceso preferencial puede consistir en:

a)

elegir una cumbre de grado mínimo en el gráfico de interferencias, el grado mínimo está definido como un número mínimo de cumbres adyacentes, y retirarlo del gráfico. Esta etapa puede ser repetida hasta que el gráfico esté vacío.

b)

Cada cumbre anteriormente retirada es introducida de nuevo en el gráfico de interferencias en el orden inverso de su retirada, la última sacada es la primera en ser introducida de nuevo y sucesivamente en el orden inverso del orden de retirada. De esta forma, a cada cumbre reintroducida, se puede atribuir el número más pequeño de registro que es diferente de los números atribuidos a todas las cumbres adyacentes.

Finalmente por la etapa (602), representada en la figura 4b, el proceso de transformación y de nueva asignación reescribe las instrucciones de acceso a los registros que figuran en el código de sub-programa de la aplicación considerada. Un acceso a un registro dado en el intervalo de duración correspondiente es sustituido por un acceso a un registro diferente cuyo número ha sido atribuido durante la fase de instanciación aún designada por la fase de coloreado.

Una descripción más detallada de un sistema informático portable que permite la puesta en práctica del protocolo de gestión y del proceso de verificación de un fragmento de programa o aplicación conforme al objeto de la presente invención y de un sistema de desarrollo de una aplicación se dará ahora en relación con la figura 6.

En lo que se refiere al sistema portable correspondiente que lleva la referencia (10), se recuerda que este sistema portable es un sistema del tipo reprogramable que consta de los elementos esenciales del modo representados en la figura 1b. Se conoce el sistema portable anteriormente citado interconectado a un terminal por una unión en serie, el terminal está él mismo unido por ejemplo por medio de una red local, en caso contrario de una red lejana, a un ordenador de desarrollo de la aplicación que lleva la referencia (20). En el sistema portable (10) funciona un programa principal que lee y ejecuta los comandos enviados en la unión en serie por el terminal. Además, los comandos standard para una tarjeta con microprocesador, tales como por ejemplo los comandos standard del protocolo ISO 7816, pueden ser puestos en práctica, el programa principal reconoce además dos comandos suplementarios, uno para la descarga de una aplicación y el otro para la selección de una aplicación anteriormente cargada en la tarjeta con microprocesador.

Conforme al objeto de la presente invención, la estructura del programa principal se ha llevado a cabo de modo que consta al menos de un módulo de programa de gestión y de verificación de un fragmento de programa descargado de acuerdo con el protocolo de gestión de un fragmento de programa descargado previamente descrito en la descripción en relación con la figura 2.

Además, el módulo de programa consta igualmente de un módulo de sub-programa de verificación de un fragmento de programa descargado de acuerdo con el procedimiento de verificación del modo descrito anteriormente en la descripción en relación con las figuras 3a a 3j.

En este objetivo, la estructura de las memorias, en particular de la memoria permanente no de lectura - escritura, memoria ROM, está modificada de modo que consta notablemente, además del programa principal, de un módulo (17) de gestión de protocolo y de verificación, del modo mencionado anteriormente. Finalmente, en lo que se refiere a la memoria no volátil de lectura - escritura de tipo EEPROM, ésta consta de modo ventajoso de un repertorio de aplicaciones, con referencia (18), que permite la puesta en práctica del protocolo de gestión y del proceso de verificación objetos de la presente invención.

Con referencia a la misma figura 6, se indica que el sistema de desarrollo de la aplicación conforme al objeto de la presente invención, que permite de hecho la transformación de un código objeto clásico del modo mencionado anteriormente en la descripción y que satisface a los criterios (C1 + C2 + C'3 + C'4) en el marco del entorno Java en un código objeto normalizado para el mismo fragmento de programa consta, asociado a un compilador clásico Java (21), de un módulo de transformación de código, con referencia (22), el cual procede a la transformación de código en un código normalizado de acuerdo con el primer y el segundo modo de realización anteriormente descritos en la descripción en relación con las figuras 4a, 4b y 5a, 5b. Se comprende de hecho que, por una parte, la normalización del código objeto de origen en un código objeto normalizado de instrucción de conexión con pila vacía y en un código normalizado que hace referencia a unos registros tipificados, por otra parte, del modo mencionado anteriormente en la descripción, permite satisfacer a los criterios de verificación (C3 y C4) impuestos por el procedimiento de verificación objeto de la presente invención.

El módulo de transformación de código (22) es seguido por un convertidor JavaCard (23), el cual permite asegurar la transmisión por una red distante o local hacia el terminal y, por medio de la unión en serie, hacia la tarjeta con microprocesador (10). De esta forma, el sistema de desarrollo de la aplicación (20) representada en la figura 6 permite transformar los ficheros de clase compilados producidos por el compilador Java (21) a partir de los códigos fuente Java de la aplicación en ficheros de clase equivalentes pero que respetan las restricciones suplementarias (C3, C4) impuestas por el protocolo de gestión y el módulo de verificación (17) portables en la tarjeta con microprocesador (10). Estos ficheros de clase transformados se convierten en una aplicación descargable en la tarjeta por el convertidor JavaCard standard (23).

Diferentes elementos particularmente notables del conjunto de los elementos del protocolo, de los procedimientos y de los sistemas objetos de la presente invención, se darán ahora a título indicativo.

En relación con unos procesos de verificación del tipo anterior del modo mencionado en la introducción a la descripción, el procedimiento de verificación objeto de la presente invención aparece notable por el hecho de que concentra el esfuerzo de comprobación en relación con las propiedades de tipificación de los operandos que son esenciales para la seguridad de la ejecución de cada aplicación, es decir del respeto de las restricciones de tipo asociadas a cada instrucción y la ausencia de desbordamiento de pila. Otras verificaciones no aparecen esenciales en términos de seguridad, en particular la comprobación que el código inicializa correctamente cada registro antes de leerlo por primera vez. El procedimiento de verificación objeto de la presente invención opera por lo contrario por inicialización a cero de todos los registros a partir de la máquina virtual durante la inicialización del método con el fin de garantizar que la lectura de un registro no inicializado no puede comprometer la seguridad de la tarjeta.

Además, la exigencia impuesta por el procedimiento de verificación objeto de la presente invención de acuerdo con la dual la pila debe estar vacía en cada instrucción de conexión o de objetivo de conexión, garantiza que la pila está en el mismo estado, vacía, después de la ejecución de la conexión y antes de la ejecución de la instrucción a la que el programa se ha conectado. Este modo de operación garantiza que la pila está en un estado coherente, sea cual sea el camino de ejecución seguido a través del código de sub-programa o de la aplicación considerada. La coherencia de la pila se garantiza de esta forma, incluso en la presencia de conexión o de objetivo de conexión. Contrario a los procedimientos y a los sistemas del tipo previo, en los cuales es necesario conservar en memoria viva el tipo de la pila en cada objetivo de conexión, lo que necesita una cantidad de memoria viva proporcional a (Tp x Nb), producida de la talla máxima de pila de ejecución utilizada y del número de objetivos de conexión en el código, el procedimiento de verificación, objeto de la presente invención, solo tiene necesidad del tipo de la pila de ejecución durante la instrucción en curso de verificación y no conserva en memoria el tipo de esta pila en otros puntos del código. En consecuencia, el procedimiento objeto de la invención se contenta con una cantidad de memoria viva proporcional a (Tp) pero independiente de (Nb), y en consecuencia de la longitud del código del sub-programa o de la aplicación.

La exigencia de acuerdo con el criterio (C4), de acuerdo con el cual un registro dado debe ser utilizado con un solo y mismo tipo en todo el código de un sub-programa, garantiza que el código anteriormente mencionado no utiliza un programa de modo incoherente, por ejemplo al escribir un entero short en un punto del programa y al volver a leerlo como una referencia de objeto en otro punto del programa.

En los procesos de verificación descritos en el tipo previo, en particular en la especificación Java titulada "The Java Virtual Machine Specification" editada por Tim LONDHOLM y Frank YELLIN, ya mencionada, para garantizar la coherencia de los usos anteriormente citados a través de las instrucciones de conexión, es necesario conservar en memoria viva una copia de la tabla de los tipos de registros en cada objetivo de conexión. Esta operación necesita una cantidad de memoria viva proporcional a (T_{r} x N_{b}) donde (T_{r}) designa la cantidad de registros utilizados por el sub-programa y (N_{b}) la cantidad de objetivos de conexión en el código de este sub-programa.

Por lo contrario, el proceso de verificación objeto de la presente invención, opera en una tabla global de tipos de registros con la ausencia de conservación en memoria viva de copia en diferentes puntos del código. En consecuencia, la memoria viva necesaria para llevar a cabo el proceso de verificación es proporcional a (T_{r}), pero independiente de (N_{b}) y por tanto de la longitud del código del sub-programa en cuestión.

La restricción de acuerdo con la cual un registro dado se usa con el mismo tipo en todos los puntos, es decir en toda instrucción del código en cuestión, simplifica sensiblemente y de modo significativo la comprobación de los sub-programas. Por lo contrario, en los procesos de verificación del tipo previo, con la ausencia de tal restricción, el proceso de verificación debe establecer que los sub-programas respetan una disciplina de pila estricta y debe comprobar el cuerpo de los sub-programas de modo polimorfo en lo que se refiere al tipo de ciertos registros.

En conclusión, el proceso de verificación objeto de la presente invención en relación con las técnicas del tipo previo permite, por una parte, reducir el tamaño del código del programa permitiendo conducir el procedimiento de verificación y por otra parte, reducir el consumo de memoria viva durante unas operaciones de verificación, el grado de complejidad es de la forma (O (T_{p} + P_{r})) en el caso del proceso de verificación objeto de la presente invención, en lugar de (O (T_{p} + P_{r}) x N_{b}) en lo que se refiere a los procesos de comprobación del tipo anterior, al ofrecer sin embargo las mismas garantías en relación con la seguridad de la ejecución del código verificado.

Finalmente, el proceso de transformación de un código clásico de origen en un código normalizado se lleva a cabo por transformación localizada del código con la ausencia de transmisión de informaciones suplementarias al órgano comprobador, es decir a la tarjeta con microprocesador o al sistema informático portable.

En lo que se refiere al procedimiento de reasignación de los registros del modo descrito en las figuras 4b y 5b, este procedimiento se distingue de los procedimientos conocidos del tipo previo descritos notablemente por la patente US 4.571.678 y por la patente US 5.249.295, por el hecho de que:

-

la reasignación de registro asegura que un mismo registro no puede ser atribuido a dos intervalos que tienen unos tipos principales diferentes, lo que garantiza de esta forma que un registro dado es utilizado con el mismo tipo en todo el código, y

-

que los algoritmos de asignaciones de registros existentes y descritos en los documentos anteriormente mencionados suponen una cantidad fija de registros e intentar reducir al mínimo las transferencias designadas por "spills" en idioma anglo-sajón, entre registros y pila, cuando la reasignación de los registros conforme con el objeto de la presente invención opera en un marco donde la cantidad total de registros es variable, en consecuencia de lo cual no hay lugar de llevar a cabo unas transferencias entre registros y pilas cuando un proceso de minimización del número total de registros se pone en práctica.

El protocolo de gestión de un fragmento de programa descargado en un sistema portable y los procedimientos de comprobación de este fragmento de programa descargado, respectivamente de transformación de este código objeto de fragmento de programa descargado, objetos de la presente invención, pueden, claro está, ser puestos en práctica de modo lógico.

A este título, la invención se refiere igualmente a un producto de programa de ordenador cargable directamente en la memoria interna de un sistema portable reprogramable, este sistema portable permiten la descarga de un fragmento de programa constituido por un código objeto, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros o variables locales manipulados por estas instrucciones con el fin de permitir la interpretación de este código objeto. El producto programa de ordenador correspondiente consta de las porciones de código objeto para la ejecución del protocolo de gestión de un fragmento de programa descargado en este sistema portable, del modo ilustrado en la figura 2 y en la figura 6, anteriormente descritos en la descripción, cuando este sistema portable está interconectado a un terminal y que este programa está ejecutado por el microprocesador de este sistema portable por medio de la máquina virtual.

La invención se refiere igualmente a un producto programa de ordenador cargable directamente en la memoria interna de un sistema portable reprogramable, tal como una tarjeta con microprocesador provista de una memoria de lectura - escritura, del modo ilustrado en relación con la figura 6. Este producto programa de ordenador que consta de las porciones de código objeto para la ejecución de las etapas de comprobación de un fragmento de un programa descargado en este sistema portable, del modo ilustrado y descrito anteriormente en la descripción en relación con las figuras 3a a 3j. Esta verificación se ejecuta cuando este sistema portable está interconectado a un terminal y que este programa es ejecutado por el microprocesador de este sistema portable por medio de la máquina virtual.

La invención se refiere igualmente a un producto programa de ordenador; este producto programa de ordenador consta de las porciones de código objeto para ala ejecución de las etapas del procedimiento de transformación del código objeto de un fragmento de programa en un código objeto normalizado para este mismo fragmento de programa, del modo ilustrado y representado en las figuras 4a, 4b, respectivamente 5a, 5b, así como en la figura 6 y descritos anteriormente en la descripción.

La presente invención se refiere igualmente a un producto programa de ordenador registrado en un soporte utilizable en un sistema portable reprogramable, una tarjeta con microprocesador provista de una memoria de lectura - escritura por ejemplo, este sistema portable que permite la descarga de un fragmento de programa constituido por un código objeto ejecutable por este microprocesador, por medio de una máquina virtual provista de una pila de ejecución y de registros o variables locales manipulados por estas instrucciones, con el fin de permitir la interpretación de este código objeto. El producto programa de ordenador anteriormente mencionado consta, al menos, de un módulo de programa legible por el microprocesador del sistema portable por medio de la máquina virtual, para mandar la ejecución de un procedimiento de gestión de la descarga de un fragmento de programa descargado, del modo representado en la figura 2 y descrito anteriormente en la descripción, un módulo de programas legibles por el microprocesador por medio de la máquina virtual para mandar la ejecución de un procedimiento de verificación, instrucción por instrucción, del código objeto que constituye el fragmento del programa, del modo ilustrado y descrito en relación con las figuras 3a a 3j en la descripción anterior, y un módulo de programas legibles por el microprocesador de este sistema portable por medio de la máquina virtual para mandar la ejecución de un fragmento de programa descargado como continuación a o en la ausencia de una transformación del código objeto de este fragmento de programa en código objeto normalizado para este mismo fragmento de programa, del modo representado en la figura 2.

El producto programa de ordenador anteriormente citado consta igualmente de un módulo de programas legibles por el microprocesador por medio de la máquina virtual para mandar la inhibición de la ejecución, en el sistema portable, del fragmento de programa en el caso de un procedimiento de verificación no lograda de fragmento de programa anteriormente mencionado, del modo ilustrado y descrito anteriormente en la descripción en relación con la figura 2.

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

(Tabla pasa a página siguiente)

\newpage

Anexos

TABLA 1

1

\vskip1.000000\baselineskip

Tabla 2

Seudo-código módulo del verificador

Variables globales utilizadas:
T_{r}	Número de registros declarado por el método corriente
T_{p}	Tamaño máximo de pila declarado por el método corriente
tr[T_{r}]	Tabla de tipos de registros (402 en la figura 4)
tp[T_{p}]	Tipo de pila (403 en la figura 4)
pp	Puntero de pila (404 en la figura 4)
chg	Bandera que indica si tr ha cambiado.

Inicializar pp 7 0

Inicializar tp[0] ... tp[n-1] a partir de los tipos de n argumentos del método

Inicializar tp[n] ... tp[T_{r} -1] a \bot

Inicializar chg a verdadero

Mientras que chg es verdadero:

Volver a poner chg a falso

Situarse en la primera instrucción del método

Mientras que el fin del método no se haya alcanzado:

Si la instrucción corriente es el objetivo de una instrucción de conexión:

si pp\neq 0, fallo de la verificación

Si la instrucción corriente es el objetivo de una llamada de sub-rutina:

Si la instrucción anterior continua en secuencia, fallo

Tomar tp[0] 7 retaddr y pp 7 1

Si la instrucción corriente es un gestor de excepciones de la clase C:

Si la instrucción precedente continua en secuencia, fallo

Hacer tp[0] 7 C y pp 7 1

Si la instrucción corriente es un objetivo de clases diferentes:

Fallo de la verificación

Determinar los tipos a_{1}, ..., a_{n} de los argumentos de la instrucción

Si pp < n, fallo (desbordamiento de pila)

Para i = 1, ..., n;

Si tp[pp-n-i-l] no es sub-tipo de a_{i}, fallo

Hacer pp 7 pp – n

Determinar los tipos r_{1}, ..., r_{m} de los resultados de la instrucción

Si pp + m \geq T_{p}, fallo (desbordamiento de pila) para i = 1, ..., m, hacer tp [pp ) i - l] 7 r_{i}

Hacer pp 7 pp ) m

Si la instrucción corriente es una escritura en un registro r:

Determinar el tipo t del valor escrito en el registro

Hacer tr[r] 7 borne inferior (t, tr[r])

Si tr[r] ha cambiado, hacer chg 7 verdadero

Si la instrucción corriente es una conexión:

Si pp\neq 0, fallo de la verificación

Avanzar a la próxima instrucción

Reenviar un código de éxito de la verificación

Tabla T3

static sort [] meth (short [] tabla)

{

short [ ] resultado = null;

if (tabla . longitud \geq 2) resultado = tabla;

Return tabla;

}

\newpage

TABLA T4 Primera iteración sobre el código del método

2

Segunda iteración sobre el código del método

3

\vskip1.000000\baselineskip

TABLA T5

(a) Violación de las restricciones de tipos sobre los argumentos de una instrucción

4

\newpage

(b) Utilización incoherente de un registro

5

\vskip1.000000\baselineskip

(c) Conexiones introduciendo unas incoherencias al nivel de la pila

6

\vskip1.000000\baselineskip

(d) Desbordamiento de pila en el interior de un lazo

7

\newpage

TABLA T6

\vskip1.000000\baselineskip

(a) Código inicial del método, anotado por los tipos de registros y de la pila

\vskip1.000000\baselineskip

8

\vskip1.000000\baselineskip

TABLA T7

\vskip1.000000\baselineskip

(b) Código del método después de la normalización de la pila al nivel de la conexión 5 6 9

\vskip1.000000\baselineskip

9

\newpage

TABLA T8

(c) Código del método después de la reasignación de los registros

10

TABLA T9

(a) Objetivo de conexión, instrucción precedente no continua en secuencia

11

\vskip1.000000\baselineskip

TABLA T10

(b) Objetivo de conexión, instrucción precedente continua en secuencia

12

TABLA T11

(c) Conexión incondicional sin argumentos

13

TABLA T12

(d) Conexión condicional a un argumento

14

Claims (27)

1. Protocolo de gestión de un fragmento de programa descargado en un sistema portable reprogramable, tal como una tarjeta con microprocesador provisto de una memoria de lectura - escritura, el mencionado fragmento de programa está constituido por un código objeto, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros o variables locales manipulados por estas instrucciones y que permiten interpretar este código objeto, el mencionado sistema portable está interconectado a un terminal, caracterizado por el hecho de que este protocolo consiste al menos, al nivel del mencionado sistema portable:

a) en detectar un comando de descarga de este fragmento de programa; y con una respuesta positiva en esta etapa que consiste en detectar un comando de descarga,

b) en leer el código objetivo que constituye este fragmento de programa y en memorizar temporalmente este código objeto;

c) en someter el conjunto del código objeto memorizado temporalmente a un proceso de verificación instrucción por instrucción, este proceso de verificación consiste al menos en una etapa de inicialización de la pila de los tipos en un estado de vacío y de la tabla de los tipos de registros a un tipo que representa la intersección de todos los tipos de datos, que representan el estado de la mencionada máquina virtual al principio de la ejecución del código objeto memorizado temporalmente y en una sucesión de etapas de verificación, instrucción por instrucción, por discriminación de la existencia, para cada instrucción corriente, de un objetivo, objetivo de instrucción de conexión, objetivo de una llamada de un gestor de excepciones u objetivo de una llamada de sub-rutina y por una verificación y una actualización del efecto de la mencionada instrucción corriente sobre la pila de los tipos y sobre la tabla de los tipos de registros, y, en el caso de una verificación lograda del mencionado código objeto,

d) en registrar el fragmento de programa descargado en un repertorio de fragmentos de programas disponibles, y, en el caso de una verificación no lograda del mencionado código objeto,

e) en inhibir la ejecución, en el sistema portable, del mencionado fragmento de programa.

2. Protocolo de acuerdo con la reivindicación 1, caracterizado por el hecho de que la mencionada etapa e) de inhibición de la ejecución consiste:

f) en borrar el fragmento de programa registrado momentáneamente, en la ausencia de registro, de este último en el mencionado repertorio de fragmentos de programas disponibles, y

g) en dirigir al mencionado lector un código de error.

3. Protocolo de acuerdo con la reivindicación 1 ó 2, caracterizado por el hecho de que con una respuesta negativa a la mencionada etapa a) que consiste en detectar un comando de descarga, este consiste:

b') en detectar un comando de selección de un fragmento de programa dispohible en un repertorio de fragmentos de programas; y, con una respuesta positiva en esta etapa que consiste en detectar un comando de selección de un fragmento de programa disponible;

c') en pedir el mencionado fragmento de programa disponible seleccionado;

d') en ejecutar el mencionado fragmento de programa disponible pedido por medio de la máquina virtual, en ausencia de toda verificación dinámica de tipos de variables, de los derechos de acceso a los objetos manipulados por el fragmento de programa disponible pedido, del desbordamiento de la pila de ejecución durante la ejecución de cada instrucción, y, con una respuesta negativa en esta etapa que consiste en detectar un comando de selección de un fragmento de programa disponible,

e') en proceder al tratamiento de los comandos standard del sistema portable.

4. Procedimiento de comprobación de un fragmento de programa descargado en un sistema portable reprogramable, tal como una tarjeta con microprocesador provisto de una memoria de lectura - escritura, el mencionado fragmento de programa está constituido por un código objeto y que consta de al menos un sub-programa, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros de operandos manipulados por estas instrucciones y que permite interpretar este código objeto, el mencionado sistema portable está interconectado a un lector, caracterizado por el hecho de que el mencionado procedimiento consiste, después de la detección de un comando de descarga y de la memorización del mencionado código objeto que se constituye de este fragmento de programa en la mencionada memoria de lectura - escritura, para cada sub-programa:

\alpha en llevar a cabo una etapa de inicialización de la pila de los tipos en un estado vacío y de la tabla de los tipos de registros en un tipo que representa la intersección de todos los tipos de datos, que representan el estado de la máquina virtual al principio de la ejecución del código objeto memorizado temporalmente;

\beta en llevar a cabo una verificación del mencionado código objeto memorizado temporalmente, instrucción por instrucción, por discriminación de la existencia, para cada instrucción corriente, de un objetivo, objetivo de instrucción de conexión, objetivo de una llamada de un gestor de excepciones u objetivo de una llamada de sub-rutina;

\nu en llevar a cabo una verificación y una actualización del efecto de la mencionada instrucción corriente en los tipos de datos de la mencionada pila de los tipos y de la mencionada tabla de los tipos de registros, en función de la existencia de un objetivo, de un objetivo de instrucción de conexión, de un objetivo de una llamada de sub-rutina o de un objetivo de una llamada de gestor de excepciones, la mencionada verificación se logra cuando la tabla de los tipos de registros no es modificada en el transcurso de una comprobación de todas las instrucciones y el proceso de verificación está continuado instrucción por instrucción hasta que la tabla de los tipos de registros esté estable, en la ausencia de modificación, el proceso de verificación está si no interrumpido.

5. Procedimiento de verificación de acuerdo con la reivindicación 4, caracterizado por el hecho de que los tipos de variables manipuladas en el transcurso del proceso de verificación constan al menos:

- de los identificadores de clases correspondientes a las clases de objetos definidos en el fragmento de programa,

- de los tipos de variables numéricas que constan al menos de un tipo short, entero codificado en p bits, y un tipo retaddr de dirección de retorno de una instrucción de salto JSR;

- de un tipo null en relación con unas referencias de objetos nulos;

- de un tipo objeto relativo a los objetos;

- de un primer tipo específico \bot, que representa la intersección de todos los tipos y que corresponde al valor 0, nil;

- de un segundo tipo específico T, que representa la unión de todos los tipos y que corresponde a todo tipo de valor.

6. Procedimiento de acuerdo con la reivindicación 5, caracterizado por el hecho de que el conjunto de los mencionados tipos de variables verifica una relación de sub-tipos:

object\gamma T;

short, retaddr \gamma T;

\bot\gammanull, short, retaddr.

7. Procedimiento de acuerdo con una de las reivindicaciones de 4 a 6, caracterizado por el hecho de que cuando la mencionada instrucción corriente es el objetivo de una Instrucción de conexión, el mencionado procedimiento de verificación consiste en comprobar que la pila de los tipos está vacía, el proceso de verificación es continuado para la instrucción siguiente en el caso de una comprobación positiva, y si no el proceso de verificación falla y el fragmento de programa es rechazado.

8. Procedimiento de acuerdo con una de las reivindicaciones de 4 a 7, caracterizado por el hecho de que cuando la mencionada instrucción corriente es el objetivo de una llamada de sub-rutina, el mencionado proceso de verificación comprueba que la instrucción precedente constituye una conexión incondicional, un retorno de subrutina o una llamada de excepción, el mencionado proceso de verificación, en el caso de una verificación positiva, procede a una reactualización de la pila de los tipos de variables por una entidad de tipo retaddr, dirección de retorno de la sub-rutina, y, si no el proceso de verificación falla y el fragmento de programa es rechazado.

9. Procedimiento de acuerdo con una de las reivindicaciones de 4 a 8, caracterizado por el hecho de que cuando la instrucción corriente es el objetivo de un gestor de excepciones, el mencionado proceso de verificación comprueba que la instrucción precedente constituye una conexión incondicional, un retorno de sub-rutina o una llamada de excepción, el mencionado proceso de verificación, en caso de verificación positiva, procede a una reactualización de la pila de los tipos por una entrada del tipo de excepciones, y si no el proceso de verificación falla y el fragmento de programa es rechazado.

10. Procedimiento de acuerdo con una de las reivindicaciones de 4 a 9, caracterizado por el hecho de que cuando la instrucción corriente es el objetivo de una pluralidad de conexiones incompatibles, el proceso de verificación falla y el fragmento de programa es rechazado.

11. Procedimiento de acuerdo con una de las reivindicaciones de 4 a 10, caracterizado por el hecho de que cuando la mencionada instrucción corriente no es el objetivo de ninguna conexión, el proceso de verificación continua por el paso a una reactualización de la pila de los tipos.

12. Procedimiento de acuerdo con una de las reivindicaciones de 4 a 11, caracterizado por el hecho de que la etapa de verificación del efecto de la instrucción corriente sobre la pila de los tipos consta al menos:

- de una etapa de verificación que la pila de ejecución de los tipos contiene al menos tantas entradas como la instrucción corriente contiene operandos;

- de una etapa de desapilamiento y de verificación que los tipos de las entradas en la cumbre de la pila son sub-tipos de los tipos de los operandos de esta instrucción;

- de una etapa de verificación de la existencia de un espacio de memoria suficiente en la pila de los tipos para proceder al apilamiento de los resultados de la instrucción corriente;

- de una etapa de apilamiento en la pila de los tipos de datos atribuidos a estos resultados.

13. Procedimiento de acuerdo con la reivindicación 12, caracterizado por el hecho de que cuando la instrucción corriente es una instrucción de lectura de un registro de dirección (n), el proceso de verificación consiste:

- en comprobar el tipo de datos del resultado de esta lectura por consulta de la entrada (n) de la tabla de los tipos de registros;

- en determinar el efecto de la instrucción corriente sobre la pila de los tipos por desapilamiento de las entradas de la pila que corresponde a los operandos de esta instrucción corriente y por apilamiento del tipo de datos de este resultado.

14. Procedimiento de acuerdo con la reivindicación 12, caracterizado por el hecho de que cuando la instrucción corriente es una instrucción de escritura de un registro de dirección (m), el proceso de verificación consiste:

- en determinar el efecto de la instrucción corriente sobre la pila de los tipos y el tipo t del operando escrito en este registro de dirección (m);

- en sustituir la entrada de tipo de la tabla de los tipos de registros en la dirección (m) por el tipo inmediatamente superior al tipo anteriormente almacenado y al tipo (t) del operando escrito en este registro de dirección (m);

15. Procedimiento de transformación de un código objeto de un fragmento de programa, en el cual los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, la pila de ejecución no representa un fenómeno de desbordamiento, para cada instrucción de conexión el tipo de las variables de pila al nivel de esta conexión es el mismo que en el nivel de los objetivos de esta conexión, en un código objeto normalizado para este mismo fragmento de programa, en el cual los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, la pila de ejecución no presenta un fenómeno de desbordamiento, la pila de ejecución está vacía en cada instrucción de conexión, y en cada instrucción de objetivo de conexión, caracterizado por el hecho de que este procedimiento consiste, para el conjunto de las instrucciones del mencionado código
objeto:

- en anotar cada instrucción corriente por el tipo de datos de la pila antes y después de la ejecución de esta instrucción, los datos de anotación se calculan por medio de un análisis del flujo de los datos relativo a esta instrucción;

- en detectar en el seno de las mencionadas instrucciones y de cada instrucción corriente la existencia de conexiones respectivamente de objetivos de conexiones para los que la mencionada pila de ejecución no está vacía, la operación de detección es llevada a partir de los datos de anotación del tipo de variables de pila asignadas a cada instrucción corriente, y en presencia de una detección de una pila de ejecución no vacía,

- en insertar unas instrucciones de transferencia de las variables de pila por una y por otra parte de estas conexiones respectivamente de estos objetivos de conexiones con el fin de vaciar el contenido de la pila de ejecución en unos registros temporales antes de esta conexión y de restablecer la pila de ejecución a partir de los mencionados registros temporales después de esta conexión, y si no a no insertar ninguna instrucción de transferencia, lo que permite obtener un código objeto normalizado para este mismo fragmento de programa, en el cual la pila de ejecución está vacía en cada instrucción de conexión y en cada instrucción de objetivo de conexión, en la ausencia de modificación de la ejecución del mencionado fragmento de programa.

16. Procedimiento de transformación de un código objeto de un fragmento de programa, en el cual los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, y un operando del tipo determinado escrito en un registro por una instrucción de este código objeto y leído de nuevo desde este mismo registro por otra instrucción de este código objeto con el mismo tipo de dato determinado, en un código objeto normalizado para este mismo fragmento de programa, en el cual los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, un solo y mismo tipo de dato está asignado a un mismo registro en todo el mencionado código objeto normalizado, caracterizado por el hecho de que este procedimiento consiste, para el conjunto de las instrucciones del mencionado código objeto:

- en anotar cada instrucción corriente por el tipo de datos de los registros antes y después de la ejecución de esta instrucción, los datos de anotación se calculan por medio de un análisis del flujo de datos relativo a esta instrucción;

- en llevar a cabo una reasignación de los registros por detección de los registros de origen empleados con unos tipos diferentes, división de estos registros de origen en registros normalizados distintos, un registro normalizado para cada tipo de dato utilizado, y una reactualización de las instrucciones que manipulan los operandos que hacen uso de los mencionados registros normalizados.

17. Procedimiento de acuerdo con la reivindicación 15, caracterizado por el hecho de que la etapa que consiste en detectar en el seno de las mencionadas instrucciones y de cada instrucción corriente la existencia de conexiones respectivamente de objetivos de conexión para la cual la pila de ejecución no está vacía consiste, después de la detección de cada instrucción de rango (i) correspondiente:

- en asociar a cada instrucción de rango (i) un conjunto de nuevos registros, un nuevo registro está asociado a cada variable de pila activa al nivel de esta instrucción;

- en examinar cada instrucción detectada de rango (i) y en discriminar la existencia de un objetivo de conexión respectivamente de una conexión, y en el caso donde la instrucción de rango (i) es un objetivo de conexión y que la pila de ejecución al nivel de esta instrucción no está vacía,

* para toda instrucción precedente, de rango (i-1), constituido por una conexión, una llamada de excepción o un retorno de programa, la instrucción detectada de rango (i) solo es accesible por una conexión,

\ae

a insertar un conjunto de instrucciones de carga load a partir del conjunto de nuevos registros anteriormente a la mencionada instrucción detectada de rango (i), con redirección de todas las conexiones hacia la instrucción detectada de rango (i) hacia la primera instrucción de carga load insertada; y

* para toda instrucción precedente, de rango (i-1), que continua en secuencia la instrucción detectada de rango (i) que es accesible a la vez por medio de una conexión y de una instrucción precedente de rango (i-1),

\ae

a insertar un conjunto de instrucciones de almacenaje store hacia el conjunto de nuevos registros anteriormente a la mencionada instrucción detectada de rango (i) y un conjunto de instrucciones de carga load a partir de este conjunto de nuevos registros, con redirección de todas las conexiones hacia la instrucción detectada de rango (i) hacia la primera instrucción de carga load insertada, y en el caso donde la mencionada instrucción detectada de rango (i) es una conexión hacia una instrucción determinada,

* para toda instrucción precedente de rango (i) constituida por una conexión incondicional,

\ae

a insertar anteriormente a la instrucción detectada de rango (i) una pluralidad de instrucciones de almacenaje store, en cada nuevo registro que está asociado una instrucción de almacenaje, y

* para toda instrucción de rango (i) constituida por una conexión condicional y para una cantidad m > 0 de operandos manipulados por esta instrucción de conexión condicional,

\ae

a insertar anteriormente a esta instrucción, detectada de rango (i) una instrucción de permutación, swap-x, en la cumbre de la pila de ejecución de los (m) operandos de la instrucción detectada de rango (i) y de los (n) valores siguientes, esta operación de permutación permite llevar a la cumbre de la pila de ejecución los n valores a salvar en el conjunto de los nuevos registros, y

\ae

a insertar anteriormente a la instrucción de rango (i) un conjunto de instrucciones de almacenaje store hacia el conjunto de nuevos registros, y

\ae

a insertar posteriormente a la instrucción detectada de rango (i) un conjunto de instrucciones de carga load a partir del conjunto de los nuevos registros.

18. Procedimiento de acuerdo con la reivindicación 16, caracterizado por el hecho de que la etapa que consiste en llevar a cabo una reasignación de los registros por detección de los registros de origen empleados con unos tipos diferentes consiste:

- en determinar los intervalos de duración de cada registro;

- en determinar el tipo de dato principal de cada intervalo de duración, el tipo de datos principal de un intervalo de duración (j) para un registro (r) que está definido por el borne superior de los tipos de datos almacenados en este registro (r) por las instrucciones de almacenaje store que pertenecen al intervalo de duración (j);

- en establecer un gráfico de interferencias entre los intervalos de duración, este gráfico de interferencias consiste en un gráfico no orientado del cual cada cumbre está constituida por un intervalo de duración y cuyos arcos entre dos cumbres (j_{1} y j_{2}) existen si una cumbre contiene una instrucción de almacenaje dirigida al registro de la otra cumbre o recíprocamente;

- en traducir la unicidad de un tipo de dato asignado a cada registro en el gráfico de interferencias al añadir unos arcos entre todo par de cumbres del gráfico de interferencias mientras que dos cumbres de un par de cumbres no tengan el mismo tipo de dato principal asociado;

- en llevar a cabo una instanciación del gráfico de interferencias, por atribución a cada intervalo de duración de un número de registro de tal forma que a dos intervalos adyacentes en el gráfico de interferencias estén atribuidos unos números de registros diferentes.

19. Sistema portable reprogramable por descarga de fragmentos de programas, que consta de al menos un microprocesador, una memoria viva, un módulo de entradas / salidas, una memoria no volátil reprogramable eléctricamente y una memoria permanente en la cual están implantados un programa principal y una máquina virtual que permiten la ejecución del programa principal y de al menos un fragmento de programa por medio del mencionado microprocesador, caracterizado por el hecho de que el mencionado sistema portable consta de al menos un módulo de programa de gestión y de verificación de un estado vacío de pila de filos tipos para cada instrucción de conexión de un fragmento de programa descargado, el módulo de programa indicado de gestión y de verificación está implantado en la memoria permanente.

20. Sistema portable reprogramable por descarga de fragmentos de programas, que consta de al menos un microprocesador, una memoria viva, un módulo de entradas / salidas, una memoria no volátil reprogramable eléctricamente y una memoria permanente en la cual están implantados un programa principal y una máquina virtual que permiten la ejecución del programa principal y de al menos un fragmento de programa por medio del mencionado microprocesador, caracterizado por el hecho de que el mencionado sistema portable consta de al menos un módulo de programa de gestión y de verificación de un fragmento de programa descargado de acuerdo con el protocolo de gestión de un fragmento de programa descargado de acuerdo con una de las reivindicaciones de 1 a 3, el mencionado módulo de programa de gestión y de comprobación está implantado en la memoria permanente.

21. Sistema portable de acuerdo con la reivindicación 20, caracterizado por el hecho de que éste consta al menos de un módulo de sub-programa de verificación de un fragmento de programa portable, de acuerdo con el proceso de verificación de acuerdo con una de las reivindicaciones de 4 a 14.

22. Sistema de transformación de un código objeto de un fragmento de programa, en el cual los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, la pila de ejecución no presenta fenómeno de desbordamiento, para cada instrucción de conexión el tipo de variables de pila al nivel de esta conexión es el mismo que al nivel de los objetivos de esta conexión y un operando de tipo determinado escrito en un registro por una instrucción de este código objeto es leído de nuevo desde este mismo registro por otra instrucción de este código objeto con el mismo tipo de dato determinado, en un código objeto normalizado para este mismo fragmento de programa en el cual los operandos de cada instrucción pertenecen a los tipos de datos manipulados por esta instrucción, la pila de ejecución no presenta fenómeno de desbordamiento, la pila de ejecución está vacía en cada instrucción de conexión y en cada instrucción de objetivo de conexión, un solo y mismo tipo de dato está asignado a un mismo registro en todo el mencionado código objeto normalizado, caracterizado por el hecho de que el mencionado sistema de transformación consta al menos, implantado en la memoria de trabajo de un ordenador de desarrollo o de una estación de trabajo, un módulo de programa de transformación de este código objeto en un código objeto normalizado según el procedimiento de acuerdo con una de las reivindicaciones de 15 a 18, lo que permite engendrar un código objeto normalizado para el mencionado fragmento de programa que satisface a los criterios de verificación de este fragmento de programa descargado.

23. Un producto programa de ordenador cargable directamente en la memoria interna de un sistema portable reprogramable, tal como una tarjeta con microprocesador provisto de una memoria de lectura - escritura, este sistema portable permite la descarga de un fragmento de programa constituido por un código objeto, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros o variables locales manipulados por estas instrucciones y que permiten interpretar este código objeto, este producto programa de ordenador que consta de las porciones de código objeto para la ejecución del protocolo de gestión de un fragmento de programa descargado en este sistema portable de acuerdo con una de las reivindicaciones de 1 a 3, cuando este sistema portable está interconectado a un terminal y que este programa es ejecutado por el microprocesador de este sistema portable por medio de la mencionada máquina virtual.

24. Un producto programa de ordenador cargable directamente en la memoria interna de un sistema portable reprogramable, tal como una tarjeta con microprocesador provisto de una memoria de lectura - escritura, este sistema portable permite la descarga de un fragmento de programa constituido por un código objeto, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros de operandos manipulados por estas instrucciones y que permiten interpretar este código objeto, este producto programa de ordenador que consta de las porciones de código objeto para la ejecución de las etapas de verificación de un fragmento de programa descargado en este sistema portable de acuerdo con una de las reivindicaciones de 4 a 14, cuando este sistema portable está interconectado a un terminal y que este programa es ejecutado por el microprocesador de este sistema portable, por medio de la mencionada máquina virtual.

25. Un producto programa de ordenador que consta de las porciones de código objeto para la ejecución de las etapas del procedimiento de transformación de un código objeto de un fragmento de programa descargado en un código objeto normalizado para este mismo fragmento de programa de acuerdo con una de las reivindicaciones de 15 a 18.

26. Un producto programa de ordenador registrado en un soporte utilizable en un sistema portable reprogramable, tal como una tarjeta con microprocesador provisto de una memoria de lectura - escritura, este sistema portable permite la descarga de un fragmento de programa constituido por un código objeto, secuencia de instrucciones, ejecutable por el microprocesador del sistema portable por medio de una máquina virtual provista de una pila de ejecución y de registros o variables locales manipulados por estas instrucciones y que permiten interpretar este código objeto, este producto programa de ordenador que consta al menos:

- de unos medios de programas legibles por el microprocesador de este sistema portable por medio de la mencionada máquina virtual, para mandar la ejecución de un procedimiento ce gestión de la descarga de un fragmento de programa descargado;

- de los medios de programas legibles por el microprocesador de este sistema portable por medio de la mencionada máquina virtual, para ordenar la ejecución de un procedimiento de verificación, instrucción por instrucción, de un estado vacío de pila de los tipos para cada instrucción de conexión del código objeto que constituye en mencionado fragmento de programa;

- de unos medios de programas legibles por el microprocesador de este sistema portable por medio de la mencionada máquina virtual para mandar la ejecución de un fragmento de programa descargado como continuación a o en ausencia de una transformación del código objeto de este fragmento de programa y en código objeto normalizado para este mismo fragmento de programa.

27. Un producto programa de ordenador de acuerdo con la reivindicación 26, que consta además de los medios de programas legibles por el microprocesador de este sistema portable por medio de la mencionada máquina virtual para ordenar la inhibición de la ejecución, en el mencionado sistema portable, del mencionado fragmento de programa en el caso de un procedimiento de verificación no logrado de este fragmento de programa.