Por Chris Lattner
Artículo Original: blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
May 14, 2011
En la Parte 1 de nuestra serie, discutimos qué es el comportamiento indefinido, y cómo permite a los compiladores de C y C++ producir aplicaciones de mayor rendimiento que los lenguajes "seguros". Este post habla de lo "inseguro" que es realmente C, explicando algunos de los efectos más sorprendentes que puede causar el comportamiento indefinido. En la Parte #3, hablamos de lo que los compiladores amigables pueden hacer para mitigar algunas de las sorpresas, incluso si no están obligados a hacerlo.
Me gusta llamar a esto "Por qué el comportamiento indefinido es a menudo una cosa aterradora y terrible para los programadores C" :-)
La interacción de las optimizaciones del compilador conduce a resultados sorprendentes
Un optimizador de compilador moderno contiene muchas optimizaciones que se ejecutan en órdenes específicos, a veces iterados, y cambian a medida que el compilador evoluciona con el tiempo (por ejemplo, cuando salen nuevas versiones). Además, los distintos compiladores suelen tener optimizadores sustancialmente diferentes. Dado que las optimizaciones se ejecutan en distintas fases, pueden producirse efectos emergentes debido a que optimizaciones anteriores modifican el código.
Veamos un ejemplo tonto (simplificado a partir de un fallo explotable que se encontró en el Kernel de Linux) para hacer esto más concreto:
void contains_null_check(int *P) {
int dead = *P;
if (P == 0)
return;
*P = 4;
}
En este ejemplo, el código comprueba "claramente" el puntero nulo. Si el compilador ejecuta la "Eliminación de Código Muerto" antes de la "Eliminación de Comprobación Nula Redundante", veremos que el código evoluciona en estos dos pasos:
void contains_null_check_after_DCE(int *P) {
//int dead = *P; // deleted by the optimizer.
if (P == 0)
return;
*P = 4;
}
y luego:
void contains_null_check_after_DCE_and_RNCE(int *P) {
if (P == 0) // Null check not redundant, and is kept.
return;
*P = 4;
}
Sin embargo, si el optimizador tiene una estructura diferente, podría ejecutar RNCE antes que DCE. Esto nos daría estos dos pasos:
void contains_null_check_after_RNCE(int *P) {
int dead = *P;
if (false) // P was dereferenced by this point, so it can't be null
return;
*P = 4;
}
y luego se ejecuta la eliminación de código muerto:
void contains_null_check_after_RNCE_and_DCE(int *P) {
//int dead = *P;
//if (false)
// return;
*P = 4;
}
Para muchos programadores (¡razonables!), eliminar la comprobación de nulos de esta función sería muy sorprendente (y probablemente presentarían un error contra el compilador :). Sin embargo, tanto "contains_null_check_after_DCE_and_RNCE" como "contains_null_check_after_RNCE_and_DCE" son formas optimizadas perfectamente válidas de "contains_null_check" según el estándar, y ambas optimizaciones son importantes para el rendimiento de varias aplicaciones.
Aunque este ejemplo es intencionadamente simple y artificioso, este tipo de cosas ocurren todo el tiempo con el inlining: inlining una función a menudo expone una serie de oportunidades de optimización secundarias. Esto significa que si el optimizador decide inlinear una función, pueden entrar en acción una serie de optimizaciones locales que cambian el comportamiento del código. Esto es perfectamente válido según la norma e importante para el rendimiento en la práctica.
El comportamiento indefinido y la seguridad no combinan bien
La familia C de lenguajes de programación se utiliza para escribir una amplia gama de código crítico para la seguridad, como núcleos, demonios setuid, navegadores web y mucho más. Este código está expuesto a entradas hostiles y los errores pueden dar lugar a todo tipo de problemas de seguridad explotables. Una de las ventajas más citadas de C es que es relativamente fácil entender lo que está pasando cuando lees el código.
Sin embargo, el comportamiento indefinido elimina esta propiedad. Después de todo, la mayoría de los programadores pensarían que "contains_null_check" haría una comprobación de nulos por encima. Mientras que este caso no es demasiado aterrador (el código probablemente se bloqueará en la tienda si se le pasa una comprobación nula, lo que es relativamente fácil de depurar) hay una amplia gama de fragmentos en C de aspecto muy razonable que son completamente inválidos. Este problema ha afectado a muchos proyectos (incluyendo el Kernel de Linux, OpenSSL, glibc, etc) e incluso llevó al CERT a emitir una nota de vulnerabilidad contra GCC (aunque mi creencia personal es que todos los compiladores de C optimizados ampliamente utilizados son vulnerables a esto, no sólo GCC).
Veamos un ejemplo. Consideremos este código C cuidadosamente escrito:
void process_something(int size) {
// Catch integer overflow.
if (size > size+1)
abort();
...
// Error checking from this code elided.
char *string = malloc(size+1);
read(fd, string, size);
string[size] = 0;
do_something(string);
free(string);
}
Este código está comprobando que malloc es lo suficientemente grande como para contener los datos leídos del fichero (porque hay que añadir un byte terminador nul), saltando si se produce un error de desbordamiento de enteros. Sin embargo, este es exactamente el ejemplo que dimos antes en el que se permite al compilador optimizar (válidamente) la comprobación. Esto significa que es perfectamente posible que el compilador convierta esto en:
void process_something(int *data, int size) {
char *string = malloc(size+1);
read(fd, string, size);
string[size] = 0;
do_something(string);
free(string);
}
Cuando se construye en una plataforma de 64 bits, es bastante probable que se trate de un fallo explotable cuando "size" es INT_MAX (quizás el tamaño de un archivo en disco). Consideremos lo terrible que es esto: un auditor de código leyendo el código pensaría muy razonablemente que se está produciendo una comprobación de desbordamiento adecuada. Alguien probando el código no encontraría ningún problema a menos que probara específicamente esa ruta de error. El código seguro parece funcionar, hasta que alguien se adelanta y explota la vulnerabilidad. En definitiva, se trata de un tipo de error sorprendente y bastante aterrador. Afortunadamente, la solución es sencilla en este caso: basta con utilizar "size == INT_MAX" o similar.
Resulta que el desbordamiento de enteros es un problema de seguridad por muchas razones. Incluso si está usando aritmética de enteros completamente definida (ya sea usando -fwrapv o usando enteros sin signo), hay una clase completamente diferente de error de desbordamiento de enteros posible. Afortunadamente, esta clase es visible en el código y los auditores de seguridad conocedores suelen ser conscientes del problema.
Depurar código optimizado puede no tener sentido
Algunas personas (por ejemplo, programadores embebidos de bajo nivel a los que les gusta mirar el código máquina generado) hacen todo su desarrollo con las optimizaciones activadas. Debido a que el código frecuentemente tiene errores cuando está siendo desarrollado, estas personas terminan viendo un número desproporcionado de optimizaciones sorprendentes que pueden conducir a comportamientos difíciles de depurar en tiempo de ejecución. Por ejemplo, omitir accidentalmente el "i = 0" en el ejemplo "zero_array" del primer artículo permite al compilador descartar completamente el bucle (compilando zero_array en "return;") porque es un uso de una variable no inicializada.
Otro caso interesante que mordió a alguien recientemente ocurrió cuando tenía un puntero de función (global). Un ejemplo simplificado es el siguiente
static void (*FP)() = 0;
static void impl() {
printf("hello\n");
}
void set() {
FP = impl;
}
void call() {
FP();
}
que clang optimiza:
void set() {}
void call() {
printf("hello\n");
}
Se le permite hacer esto porque llamar a un puntero nulo es indefinido, lo que le permite asumir que set() debe ser llamado antes de call(). En este caso, el desarrollador olvidó llamar a "set", no se bloqueó con una desviación de puntero nulo, y su código se rompió cuando alguien más hizo una compilación de depuración.
El resultado es que es un problema solucionable: si sospechas que algo raro está pasando, intenta compilar en -O0, donde es mucho menos probable que el compilador esté haciendo optimizaciones.
El código "funcional" que utiliza un comportamiento indefinido puede "romperse" a medida que el compilador evoluciona o cambia.
Hemos visto muchos casos en los que aplicaciones que "parecen funcionar" de repente se rompen cuando se utiliza un LLVM más nuevo para compilarlas, o cuando la aplicación se ha movido de GCC a LLVM. Mientras que LLVM tiene ocasionalmente un error o dos :-), esto es más a menudo debido a errores latentes en la aplicación que ahora están siendo expuestos por el compilador. Esto puede ocurrir de diferentes maneras, dos ejemplos son:
1. una variable no inicializada que fue inicializada a cero por suerte "antes", y ahora comparte algún otro registro que no es cero. Esto es comúnmente expuesto por cambios en la asignación de registros.
2. un desbordamiento de array en la pila que empieza a clobber una variable que realmente importa, en lugar de algo que estaba muerto. Esto se expone cuando el compilador reorganiza la forma en que empaqueta las cosas en la pila, o se vuelve más agresivo a la hora de compartir el espacio de la pila para valores con tiempos de vida que no se solapan.
Lo importante y aterrador es darse cuenta de que casi *cualquier* optimización basada en un comportamiento indefinido puede empezar a activarse en código con errores en cualquier momento en el futuro. Inlining, loop unrolling, memory promotion y otras optimizaciones seguirán mejorando, y una parte significativa de su razón de existir es exponer optimizaciones secundarias como las anteriores.
Para mí, esto es profundamente insatisfactorio, en parte porque inevitablemente se acaba culpando al compilador, pero también porque significa que enormes cuerpos de código C son minas terrestres a punto de explotar. Esto es aún peor porque...
No hay forma fiable de determinar si una gran base de código contiene comportamientos indefinidos.
Hacer de la mina terrestre un lugar mucho peor es el hecho de que no hay una buena manera de determinar si una aplicación a gran escala está libre de comportamiento indefinido, y por lo tanto no es susceptible de romperse en el futuro. Hay muchas herramientas útiles que pueden ayudar a encontrar algunos de los errores, pero nada que dé plena confianza de que su código no se romperá en el futuro. Veamos algunas de estas opciones, junto con sus puntos fuertes y débiles:
1. La herramienta memcheck de Valgrind es una forma fantástica de encontrar todo tipo de variables no inicializadas y otros errores de memoria. Valgrind está limitado porque es bastante lento, sólo puede encontrar errores que todavía existen en el código máquina generado (por lo que no puede encontrar cosas que el optimizador elimina), y no sabe que el lenguaje fuente es C (por lo que no puede encontrar errores de desplazamiento fuera de rango o desbordamiento de enteros con signo).
2. Clang tiene un modo experimental -fcatch-undefined-behavior mode que inserta comprobaciones en tiempo de ejecución para encontrar violaciones como cantidades de shift fuera de rango, algunos errores simples de array fuera de rango, etc. Esto es limitado porque ralentiza el tiempo de ejecución de la aplicación y no puede ayudarte con desferencias aleatorias de punteros (como Valgrind), pero puede encontrar otros errores importantes. Clang también soporta completamente la opción -ftrapv (no confundir con -fwrapv) que hace que los bugs de desbordamiento de enteros con signo se atrapen en tiempo de ejecución (GCC también tiene esta opción, pero es completamente poco fiable/deficiente en mi experiencia). Aquí hay una demostración rápida de -fcatch-undefined-behavior:
$ cat t.c
int foo(int i) {
int x[2];
x[i] = 12;
return x[i];
}
int main() {
return foo(2);
}
$ clang t.c
$ ./a.out
$ clang t.c -fcatch-undefined-behavior
$ ./a.out
Illegal instruction
3. Los mensajes de advertencia del compilador son buenos para encontrar algunas clases de estos errores, como variables no inicializadas y errores simples de desbordamiento de enteros. Tiene dos limitaciones principales: 1) no tiene información dinámica sobre tu código mientras se ejecuta, y 2) debe ejecutarse muy rápido porque cualquier análisis que haga ralentiza el tiempo de compilación.
4. El Analizador Estático de Clang realiza un análisis mucho más profundo para tratar de encontrar errores (incluyendo el uso de comportamientos indefinidos, como las referencias a punteros nulos). Puedes pensar en él como un generador de mensajes de advertencia del compilador mejorado, porque no está limitado por las restricciones de tiempo de compilación de las advertencias normales. Las principales desventajas del analizador estático es que 1) no tiene información dinámica sobre tu programa mientras se ejecuta, y 2) no está integrado en los flujos de trabajo normales de muchos desarrolladores (aunque su integración en Xcode 3.2 y posteriores es fantástica).
5. El subproyecto "Klee" de LLVM utiliza el análisis simbólico para "probar todos los caminos posibles" a través de un fragmento de código para encontrar errores en el código y produce un caso de prueba. Es un pequeño gran proyecto que está limitado principalmente por no ser práctico para ejecutarse en aplicaciones a gran escala.
6. Aunque nunca la he probado, la herramienta C-Semantics de Chucky Ellison y Grigore Rosu es una herramienta muy interesante que aparentemente puede encontrar algunos tipos de errores (como violaciones del punto de secuencia). Todavía es un prototipo de investigación, pero puede ser útil para encontrar fallos en programas (pequeños y autocontenidos). Recomiendo leer el post de John Regehr al respecto para obtener más información.
El resultado final de esto es que tenemos un montón de herramientas en la caja de herramientas para encontrar algunos errores, pero no hay una buena manera de demostrar que una aplicación está libre de comportamiento indefinido. Dado que hay muchos errores en aplicaciones del mundo real y que C se utiliza para una amplia gama de aplicaciones críticas, esto da bastante miedo. En nuestro último artículo, examino varias opciones que tienen los compiladores de C para tratar el comportamiento indefinido, con un enfoque específico en Clang.
What Every C Programmer Should Know About Undefined Behavior #1/3
What Every C Programmer Should Know About Undefined Behavior #3/3
