Esta publicación de blog en particular no tratará sobre la administración de la memoria de Linux y su seguridad o cómo escribir un software crítico para la seguridad, sino que tocará el tema que todo software crítico para la seguridad debe abordar correctamente. Este tema es Libre de interferencias (FFI). Antes de sumergirnos, definamos algunos términos y qué significan en realidad:
| ISO26262 | Estándar automotriz para la seguridad funcional | Esto le brinda alguna orientación sobre lo que debe hacer para crear un software crítico para la seguridad. Al menos en automoción. Si le interesa principalmente el software, la Parte 6 de este estándar es la más importante. |
| control de calidad | Software de gestión de calidad | No es un software crítico para la seguridad. Puede (y lo hará) volverse loco y comenzar a escribir en su memoria o detener la CPU. |
| ANUNCIO ASIL | Nivel de integridad del software automotriz | Software crítico de seguridad para automoción. Este software también puede volverse loco. Pero la probabilidad de que esto suceda es limitada. Cuánto limitado depende del nivel de integridad donde ASIL D es la integridad más alta. |
La Parte 6 de ISO26262 define la ausencia de interferencias como la ausencia de fallas en cascada entre los componentes del software. En otras palabras, cómo garantizar que el componente crítico para la seguridad funcione según lo diseñado sin dar la oportunidad a otros (componente menos crítico) de afectar la ejecución. Hay en general 3 tipos de interferencia: espacial (memoria), temporal (programación) y comunicación (corrupción de datos de entrada y salida). Y como sugiere el título, aquí trataremos en detalle solo un mecanismo de protección de memoria independiente del hardware en particular.
Pero, en general, hay varios mecanismos más en los que uno puede pensar cuando se trata de la libertad espacial de interferencia:
Como se dijo, esta publicación trata principalmente sobre (1): proteger una sección de memoria determinada de un proceso con suma de verificación. Esto se ilustrará en un ejemplo para el sistema operativo Linux, pero esencialmente (como verá más adelante) es más adecuado para aplicaciones más completas. En todos los entornos, se supondrá que cualquier otro proceso con ASIL (o QM) más bajo que el nivel de integridad deseado de su componente puede (y lo hará) ejecutarse incorrectamente y cambiará (si tiene la oportunidad) su memoria. A menudo no podemos evitar que esto suceda, pero al menos podemos asegurarnos de detectarlo a tiempo y tomar medidas correctivas.
Pero sin más preámbulos, pasemos al ejemplo. Todo el código fuente que se muestra aquí (y más) se puede encontrar en GitHub aquí.
Nota completa desde el Blog oficial de SUSE.
Linware Perú ⯈