Hola Andres, que decis, interesante post
Andres Valloud wrote:
> Una funcion que no esta en la lista es printf(). Por lo tanto, no es
> seguro usar printf() en signal handlers para debuggear cosas. Ahora,
> supongamos que uno "es macho y se la banca" (digamos) y usa printf()
> lo mismo. Para debuggear, entonces, el programa puede *parecer*
> funcionar.
Es un problema con el que me topé alguna vez, y que en algún
momento estudié a fondo... aunque nunca supe de esa lista de
funciones permitidas desde los signal handlers. Básicamente,
creo, si mirás con detalle, lo que no está definido muy bien es
que pasa con la alocación de memoria (syslog(), printf(), fopen(),
fclose(), etc. hacen internamente alocación o deallocaion de memoria).
Y con un poco más de detalle, si dentro de malloc() o free() cae
un signal, y malloc() es interrumpido en un momento donde el heap
no es coherente, y despues desde el signal handler querés de nuevo
operar sobre el heap, entonces es posible que el programa se rompa...
y, en ese caso...
> El tema es esa palabrita, "undefined". Si nuestro programa llega al
> punto de tener *undefined behavior*, entonces, desde el momento que
> (en nuestro ejemplo) se ejecuta printf() en un signal handler, no es
> posible hacer ninguna suposicion acerca de nada. Si nuestro programa
> parece funcionar, pues bien gracias, pero nada dice que en alguna otra
> oportunidad la conducta no vaya a ser "formatear todos los discos,
> seguido de un colgazo".
>
jeje, "formatear todos los discos" es un poco exagerado... o no?
ja: NO, NO ES EXAGERADO, por que?
"undefined behavior" en realidad, en una compu, no existe (no?)
y en cambio si existen algo así como "condiciones de contexto
desconocidas", pero que pasa cuando alguien puede controlar el
contexto y forzar que se produsca la situación donde se "ejecuta
el undefined behavior"? Esto es un caso típico de problema de
seguridad, y hay toda una familia de problemas de seguridad que
tienen que ver con signal handlers que usan funciones unsafe:
El atacante, controlando el timing y contenido de paquetes (por
ejemplo) puede forzar (estadísticamente) a que un signal caiga en
el momento preciso, y de esta forma forzar un problema en el heap
que resulta una problema de seguridad, y generalmente este tipo
de problemas de seguridad (corrupción de heap) termina en
ejecucion arbitraria de código.
más cortito: es peor de lo que pensabas :(
y bueno, en cuanto a los standares de Smalltalk... Creo que como
vos decis, todas las aplicaciónes en Smalltalk estan montadas sobre
algunas librerias (y SqueakNOS? :), y estas librerias seguro tienen
algún tipo de standares o condiciones de contexto (parámetros
implícitos) que pueden ser manipulados (bien o mal, a propósito o
sin querer) desde Smalltalk. Que seamos siegos a todo esto lo hace
peor, porque de todas formas los problemas están ahí en algún lado...
Erm... ejemplo facil: en Smalltalk un string puede ser tan largo como
quieras, pero que pasa si lo usas como filename? que pasa si querés
abrir 2 archivos con un nombre de 5000 caracteres y que solo se
diferencian en el ultimo? ja, yo tampoco se... y ese desconocimiento
es suficiente para probar mi punto (y el tuyo) :)
saludos,
richie
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
-~----------~----~----~----~------~----~------~--~---
