Nadie sugirió una respuesta definitiva, así que hice un pequeño experimento. Basado en este experimento, aquí está mi recomendación hasta ahora:
Recomendación. Al fuzzing, puedes considerar configurar las variables de entorno LIBC_FATAL_STDERR_=1 MALLOC_CHECK_=3 . Esta configuración no tuvo un impacto medible en el rendimiento en mi experimento y, según mis resultados, esta configuración podría aumentar ligeramente la cantidad de errores que detectas.
Ninguna de las otras configuraciones hizo una diferencia detectable en mi experimento.
Opcional. Si lo deseas, puedes compilar con -fstack-protector o -fstack-protector-all , con -O2 -D_FORTIFY_SOURCE=2 , y / o con mudflap; y puede ejecutar con la variable de entorno G_SLICE=debug-blocks . Ninguno de ellos tuvo un impacto medible en el rendimiento en mi experimento. Sin embargo, ninguno de ellos tuvo ningún impacto en el conjunto de errores encontrados. Entonces, si bien no hubo costo en mi experimento, tampoco hubo beneficio.
Metodología experimental y detalles. En cada ejecución, confundí ffmpeg con zzuf , utilizando un archivo semilla, para 5000 iteraciones. Hubo una ejecución por configuración de indicadores de compilador / variables de entorno. Me aseguré de que fuzzing generara exactamente el mismo conjunto de archivos de variante en cada ejecución, por lo que la única diferencia era el compilador de indicadores / variables de entorno. Para medir el impacto en el rendimiento, medí el tiempo de CPU + del sistema para completar el difuminado. Para medir el impacto en la capacidad de detectar errores, registré qué archivos de variantes provocaron un bloqueo detectable.
Medí el rendimiento, pero ninguna de las opciones tuvo un efecto detectable en el rendimiento (las diferencias fueron de < 1% en todos los casos, y probablemente debido al ruido aleatorio).
Para el poder de detección de errores, I MALLOC_CHECK_=3 dio una ligera ventaja, pero ninguna de las otras marcas o configuraciones hizo alguna diferencia en el poder de detección de errores:
-
MALLOC_CHECK_=3 tuvo una influencia en qué archivos de variantes provocaron un bloqueo. Sin banderas, 22 de las 5000 iteraciones causaron un choque. Otras 2 iteraciones causaron un mensaje de advertencia ( *** glibc detected *** ...) que, si supiera buscarlo, se podría usar para detectar un error, por lo que si era lo suficientemente inteligente como para grep sus registros de confusión para ese mensaje, 24 de las 5000 iteraciones darían señales de un error, mientras que si no conoce los registros para ese mensaje de advertencia en particular, solo 22 de las 5000 iteraciones proporcionaron indicaciones de un error. En contraste, cuando habilité MALLOC_CHECK_=3 , 25 de las 5000 iteraciones causaron un bloqueo y no hubo necesidad de grep en los registros. Por lo tanto, MALLOC_CHECK_=3 ambos es ligeramente más efectivo para descubrir signos de un error, y también reduce la necesidad de postprocesar sus registros de confusión especialmente.
Interesantemente, hubo un archivo de variantes que bloqueó el programa sin configuraciones pero no lo hizo con MALLOC_CHECK_=3 , lo que confirma la hipótesis de @ this.josh de que la comprobación adicional en algunos casos podría hacer que nos perdamos algunos errores. pero al mismo tiempo, hubo 2 archivos de variantes que no bloquearon el programa sin configuraciones, pero que lo hicieron con MALLOC_CHECK_=3 . Por lo tanto, los beneficios de MALLOC_CHECK_=3 superaron sus costos.
-
Aparte de MALLOC_CHECK_ , ninguna de las otras configuraciones tuvo influencia alguna en los archivos de variantes que provocaron un bloqueo detectable. El conjunto de archivos de variantes que causaron que el programa de línea de base (sin indicadores especiales) se bloquee fue exactamente igual que el conjunto de archivos de variantes que causaron que el programa fallara cuando se compila con indicadores especiales. Por lo tanto, al menos en este experimento, esas otras configuraciones no nos costaron nada (en el rendimiento), pero tampoco nos ganaron nada (en el poder de detección de errores).
Mi experimento está lejos de ser autoritario. Para hacer esto bien, uno debería probarlo con muchos programas diferentes (no solo uno) y múltiples archivos semilla diferentes (no solo uno). Así que le advierto que no saque demasiadas conclusiones de este pequeño experimento. Pero pensé que los resultados eran interesantes, no obstante.