Experimento de seguridad en Windows y Linux

Archivado
Hoy he hecho un test básico de estress, me ha sorprendido mucho las reacciones que he tenido.

Tenemos el siguiente programa:
#include <iostream>

using namespace std;

int main()
{
    char* Memoria;
    cout << "Satura memoria. Programa creado por amchacon" << endl;

    do
    {
        Memoria = new(nothrow) char;
    } while(Memoria != NULL);

    cin.get();
    return 0;
}

https://dl.dropboxusercontent.com/u/695 ... 20bits.exe

Lo que hace es pedir continuamente memoria al sistema operativo. He compilado este programa en 64 bits y lo he ejecutado en Windows 7. La reacción ha sido la siguiente:

El programa ha ido ocupando memoria, cuando ha llegado al 100% ha empezado a tirar de pagefile congelando el ordenador. Cuando se le acabó el pagefile ha ocurrido el desastre (el SO se ha bloqueado por completo, no había memoria ni para abrir el administrador de tareas). He pulsado el botón de la torre pero no ha habido respuesta, al final he tenido que desenchufar.

Viendo la reacción de Windows, he probado a ejecutarlo en Debian 64 bit (desde VirtualBox por si acaso). Cuando se le ha agotado la memoria también ha tirado de Pagefile y se ha quedado también congelado. La diferencia está en que cuando se le acabó, Linux mató el proceso automáticamente.

Para comprobar todas las alternativas, ejecuté el programa como Root. Ahí no podía matarlo, por lo que cerró la sesión y me devolvió la pantalla de inicio.

La verdad esque estoy sorprendido con la reacción de Linux. Supo defenderse bastante bien, incluso aunque la aplicación se ejecutara con privilegios máximos.
GNU/Linux si ve que un proceso intenta monopolizar la ram o que necesita mas ram, libera ram matando el proceso que seguramente sera el causante del problema.
Si mato las X antes que el programa seguramente las considero que había otras prioridades (root no son programas para nivel usuario vamos XD).

La gestión de ram en GNU/Linux es bastante eficiente ademas de ampliamente configurable.
A menor escala podeis verlo en Android y el tema de taskiller donde se recomiendan a menos que se queden pillados apps y se vea que el propio android no las mata al no reconocerlas como perjudiciales (no hay prioridades si no son del propio sistema).
blackgem escribió:Si mato las X antes que el programa seguramente las considero que había otras prioridades (root no son programas para nivel usuario vamos XD).

Sí, pero aún así me llamo la atención que pudiera resolver el problema sin llegar a reiniciar el equipo (en Windows se me quedó bloqueado, y eso que no llegué a ejecutarlo como administrador xD).

blackgem escribió:A menor escala podeis verlo en Android y el tema de taskiller donde se recomiendan a menos que se queden pillados apps y se vea que el propio android no las mata al no reconocerlas como perjudiciales (no hay prioridades si no son del propio sistema).

En realidad si hay prioridades a la hora de liberar memoria, cuando está falto de memoria Android mata en este orden:

- Procesos en blanco: Aplicaciones que se han cerrado y se mantienen en memoria como caché por si se vuelven a ejecutar en un futuro. Si es necesario liberar memoria se borran en orden cronologico (la más viejas primero).
- Servicios: Son todas los procesos en segundo plano (por ejemplo, el wasap). Si hiciera falta, se pueden matar estos procesos para que la aplicación en primer plano pueda seguir corriendo.
- Procesos ocultos: Una aplicación que se ha abierto pero posteriormente se ha ocultado (por ejemplo, estas mirando el correo y pulsas un enlace. El correo se oculta y se abre el navegador).
- Proceso en primer plano: El programa que estás corriendo, evidentemente esto es el ultimo recurso.

Y bueno, en teoría Android da un mensaje de "Esta aplicación no responde" si su hilo de ejecución principal se bloquea más de 5 segundos.
amchacon escribió:
blackgem escribió:Si mato las X antes que el programa seguramente las considero que había otras prioridades (root no son programas para nivel usuario vamos XD).

Sí, pero aún así me llamo la atención que pudiera resolver el problema sin llegar a reiniciar el equipo (en Windows se me quedó bloqueado, y eso que no llegué a ejecutarlo como administrador xD).

Es gracias al OOM-killer:

http://linux-mm.org/OOM_Killer
amchacon escribió:
blackgem escribió:Si mato las X antes que el programa seguramente las considero que había otras prioridades (root no son programas para nivel usuario vamos XD).

Sí, pero aún así me llamo la atención que pudiera resolver el problema sin llegar a reiniciar el equipo (en Windows se me quedó bloqueado, y eso que no llegué a ejecutarlo como administrador xD).

blackgem escribió:A menor escala podeis verlo en Android y el tema de taskiller donde se recomiendan a menos que se queden pillados apps y se vea que el propio android no las mata al no reconocerlas como perjudiciales (no hay prioridades si no son del propio sistema).

En realidad si hay prioridades a la hora de liberar memoria, cuando está falto de memoria Android mata en este orden:

- Procesos en blanco: Aplicaciones que se han cerrado y se mantienen en memoria como caché por si se vuelven a ejecutar en un futuro. Si es necesario liberar memoria se borran en orden cronologico (la más viejas primero).
- Servicios: Son todas los procesos en segundo plano (por ejemplo, el wasap). Si hiciera falta, se pueden matar estos procesos para que la aplicación en primer plano pueda seguir corriendo.
- Procesos ocultos: Una aplicación que se ha abierto pero posteriormente se ha ocultado (por ejemplo, estas mirando el correo y pulsas un enlace. El correo se oculta y se abre el navegador).
- Proceso en primer plano: El programa que estás corriendo, evidentemente esto es el ultimo recurso.

Y bueno, en teoría Android da un mensaje de "Esta aplicación no responde" si su hilo de ejecución principal se bloquea más de 5 segundos.


Curso de android de miriadax no? XD

dark_hunter escribió:
amchacon escribió:
blackgem escribió:Si mato las X antes que el programa seguramente las considero que había otras prioridades (root no son programas para nivel usuario vamos XD).

Sí, pero aún así me llamo la atención que pudiera resolver el problema sin llegar a reiniciar el equipo (en Windows se me quedó bloqueado, y eso que no llegué a ejecutarlo como administrador xD).

Es gracias al OOM-killer:

http://linux-mm.org/OOM_Killer


Ahí el culpable, mira que nunca recuerdo su nombre pero me acuerdo siempre que me pongo a dejar procesos potentes ahí detrás corriendo XD.
en linux hay un comando que pones en la consola y peta XD
":(){ :|:& };:" pero sin ""
+info bomba fork
dolpsdw escribió:en linux hay un comando que pones en la consola y peta XD
":(){ :|:& };:" pero sin ""
+info bomba fork

No "peta". Puede petar si tu sistema no tiene configurados ciertos limites, pero raro seria.
hace 1 mes en ubuntu 12.04 x86 recuerdo aver tenido que reiniciar entero.

Me parece que no me espere a que se colapasara del todo,

PDta: han jake4do eol ?
Hace un segundo me salia un error sql con user eoltest y nosecuantas sesiones activas.
dolpsdw escribió:hace 1 mes en ubuntu 12.04 x86 recuerdo aver tenido que reiniciar entero.

Me parece que no me espere a que se colapasara del todo,

PDta: han jake4do eol ?
Hace un segundo me salia un error sql con user eoltest y nosecuantas sesiones activas.


puedes hacer un ulimit -a para ver los distintos limites impuestos que tienen los procesos de un usuario
JanKusanagi escribió:
dolpsdw escribió:en linux hay un comando que pones en la consola y peta XD
":(){ :|:& };:" pero sin ""
+info bomba fork

No "peta". Puede petar si tu sistema no tiene configurados ciertos limites, pero raro seria.


Confirmado hace 5 minutos: Linux Mint 13, con la configuración por defecto, peta.

Y de testigos están el resto de usuarios de la biblioteca, que han comprobado cómo mi portátil se transformaba en un reactor.
A mi con Arch también me a petado con ese comando.
y ese comando que hace?
anonimo95 escribió:y ese comando que hace?


cada proceso realiza un fork (mmmm.. crea otro proceso con el mismo código que el proceso padre) y vuelta a empezar.

Básicamente se crea gran cantidad de procesos, hasta que llenas la tabla de descriptores de procesos y no puedes crear ningún proceso mas.

Solución limitar el número máximo de procesos por usuario. La cuenta de ese usuario quedará limitada, pero el resto de usuarios podrán seguir usando la máquina.
nu_kru escribió:
anonimo95 escribió:y ese comando que hace?


cada proceso realiza un fork (mmmm.. crea otro proceso con el mismo código que el proceso padre) y vuelta a empezar.

Básicamente se crea gran cantidad de procesos, hasta que llenas la tabla de descriptores de procesos y no puedes crear ningún proceso mas.

Solución limitar el número máximo de procesos por usuario. La cuenta de ese usuario quedará limitada, pero el resto de usuarios podrán seguir usando la máquina.

fedora lo trae limitado a 1000 en total :)
Yo hice una prueba como la del principio del hilo pero creando hilos a lo loco. Le mandé crear 65535 hilos en Java y Windows se empezó a quedar pillado, la música se cortaba y al final me llevé un pantallazo azul, en cambio en Linux Mint sobrevivió (el proceso tenía fin, cada hilo analizaba un puerto de mi NAS a ver si estaba abierto o no y cuando los analizaba todos finalizaba el programa). Lo sorprendente es que en Linux estaba con un vídeo de Youtube puesto de fondo para escuchar música y ni se notaba que el programa estaba en ejecución, excepto por el comando top que a veces me marcaba que estaba usando el 600% de CPU. Las pruebas las hice sobre un i7 2600K overclockeado a 4Ghz con 8 gigas de memoria.
Yo acabo de hacer la prueba en W7 64 bits y en mi caso no se ha bloqueado por completo. Tenía abiertos Steam, Chrome con bastantes pestañas y algunos programas en segundo plano (Feedly, Dropbox, etc). Efectivamente empezó a rascar al llenarse la RAM (4GB) y se puso a tirar de archivo de paginación. Se podía mover el ratón, pero las ventanas no respondían. Al rato (supongo que cuando se ha quedado sin memoria virtual) ha puesto el tema básico de Windows, ha cerrado Chrome, ha cerrado Steam para liberar memoria y poder seguir reservando y, finalmente, ha finalizado la aplicación de la memoria, momento en el cual todo ha vuelto a la normalidad.
15 respuestas
Archivado
Volver a Software libre