kernel

  • Generalmente la partición /boot suele tener un tamaño reducido en disco, ya que se utiliza para guardar el kernel Linux, la imagen initrd y el bootloader. El problema es que, al pasar el tiempo y las actualizaciones, se van acumulando versiones antiguas del kernel Linux hasta llenar la partición boot. Este artículo explica cómo eliminar las versiones del kernel viejas/desactualizadas en un sistema CentOS para ganar espacio en la partición /boot.

  • El kernel es el núcleo del sistema operativo. Es responsable por manejar la memoria, asegurar controles de seguridad, redes, acceso a disco, y más. Tradicionalmente, FreeBSD usaba un kernel monolítico: un gran programa que soportaba una lista fija de dispositivos, donde, para cambiar su comportamiento, era necesario compilarlo para adaptarlo a nuestras necesidades. En la actualidad se trata de un kernel modular. La mayoría de las funcionalidades del kernel FreeBSD están contenidas en módulos que pueden ser cargados en el kernel dinámicamente a medida que sea necesario.

    Pero, a pesar de esta flexibilidad, compilar el kernel tiene muchas ventajas. Por ello en este artículo voy a explicar cómo compilar un kernel personalizado en FreeBSD 10.

  • El menú del gestor de inicio (bootloader) de FreeBSD permite seleccionar con qué kernel (núcleo del sistema operativo) iniciar mediante la opción 5. Generalmente esto permite cambiar entre el último kernel disponible (/boot/kernel/) y el kernel anterior (/boot/kernel.old/). Sin embargo es posible seleccionar cualquier kernel que se encuentre dentro del directorio /boot/ lanzando el proceso de boot de forma manual.

  • Este artículo explica cómo obtener las opciones configuradas actualmente en el kernel en un sistema FreeBSD.

  • Recientemente se descubrió una vulnerabilidad en el kernel Linux que afecta a todas las versiones 2.6.31. Por ello, en este artículo voy a demostrar cómo determinar si la versión del kernel Linux en un sistema GNU/Linux está actualizada.

  • En este artículo comparto un pequeño programa escrito en lenguaje C para verificar si un filesystem soporta direct I/O (flag O_DIRECT al abrir archivos).

  • Luego de muchas actualizaciones se apilaron unas cuantas versiones del kernel Linux en mis servidores Debian. Veamos cómo ejecutar apt-get autoremove en todos los servidores Debian al mismo tiempo con un simple playbook de Ansible.

  • Esto nos advirtió RMS infinidad de veces al referirse a la inclusión de código binario en el kernel Linux:

    Puede que, con la inclusión de un parche, Linus permitiese que Intel colara una puerta para la NSA en el Kernel

  • Los últimos años han sido una catástrofe tras otra para Intel en lo que a seguridad respecta. Todas las variantes de los ataques Meltdown y Spectre, al igual que el reciente ZombieLoad, requieren parches y protecciones que terminan degradando la performance de los procesadores Intel. Para el caso de ZombieLoad no hay forma de estar seguro sin deshabilitar Hyper-Threading, lo cual es un altísimo precio a pagar. Apple ha confirmado que el parche para mitigar ZombieLoad trae consigo una pérdida del 40% de rendimiento:

    Full mitigation requires using the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology. This capability is available for macOS Mojave, High Sierra, and Sierra in the latest security updates and may reduce performance by up to 40 percent2, with the most impact on intensive computing tasks that are highly multithreaded.

    Pero para agravar aún más la situación, deshabilitar SMT/Hyper-Threading para obtener protección total contra MDS/ZombieLoad en conjunto con el código para mitigar Meltdown y Spectre (y todas sus variantes), y otras vulnerabilidades, resulta catastrófico para el rendimiento de la CPU.

    Cabe destacar que se trata de vulnerabilidades del hardware, no son vulnerabilidades del sistema operativo, y tanto en Linux como Windows u otro sistema operativo las soluciones implican pérdidas de rendimiento. La solución sería cambiar los procesadores por otra marca (léase AMD).

    Ahora bien, ¿que tal si uno tiene un procesador Intel y no está dispuesto a perder tanto rendimiento en un sistema hogareño que será utilizado para juegos o películas? Este artículo explica cómo deshabilitar todas las protecciones de seguridad del kernel Linux que degradan el rendimiento en procesadores Intel. ¡Al carajo con la seguridad!

  • Combinando la salida leída del dispositivo /dev/random (generador de números aleatorios del kernel Linux) con tr y head, es posible generar diferentes tipos de cadenas de caracteres (strings) ya sea para utilizar en scripts, crear claves o contraseñas, o simplemente divertirse un rato (?)

    He aquí algunos ejemplos.

  • Los sistemas Linux actuales tienen ciertos procesos que ejecutan código del kernel Linux, pero son manejados como procesos del espacio usuario en lo que respecta a planificación (scheduling). Sin embargo no respetan las reglas típicas de manejo de memoria ya que corren código del kernel.

    Estos procesos son creados por kthreadd, el cual es una especie de init para procesos del kernel. Es posible reconocerlos porque usualmente la herramienta ps los lista con un nombre entre corchetes:

    root@debian9:~# ps -ef | grep '\[' | head -n 10
    root         1     0  0  2018 ?        00:01:38 init [2]
    root         2     0  0  2018 ?        00:00:23 [kthreadd]
    root         3     2  0  2018 ?        00:00:00 [rcu_gp]
    root         7     2  0  2018 ?        00:00:00 [mm_percpu_wq]
    root         8     2  0  2018 ?        00:00:13 [ksoftirqd/0]
    root         9     2  0  2018 ?        00:41:15 [rcu_sched]
    root        10     2  0  2018 ?        00:00:00 [rcu_bh]
    root        11     2  0  2018 ?        00:00:00 [migration/0]
    root        12     2  0  2018 ?        00:00:24 [watchdog/0]
    root        13     2  0  2018 ?        00:00:00 [cpuhp/0]
    

    Los hilos del kernel no son hijos de init ya que pueden ser iniciados antes de que arranque el espacio usuario (userland, PID 1 en adelante). Estos procesos típicamente se encargan de manejar hardware, por eso son gestionados directamente por el kernel y tienen alta prioridad.

    Este artículo demuestra cómo ocultar estos procesos en la salida de ps.

  • Jugando con una instalación de Devuan decidí habilitar los backports de Jessie, desde los cuales instalé un kernel Linux que tiene un bug de Debian por el cual no bootea (no inicia). En este artículo voy a explicar las alternativas al momento de reparar un sistema GNU/Linux (basado en Debian) que no inicia. Específicamente, cómo solucionar problemas con un kernel Linux que no bootea.

  • Algo que me había quedado pendiente luego de instalar FreeBSD era hacer funcionar los auriculares en el jack del panel frontal de audio de mi gabinete. Algo que anteriormente funcionaba perfectamente en Linux. La solución es bastante simple y consiste en setear correctamente el dispositivo de salida por defecto en el kernel de FreeBSD.

  • Si recuerdan, hace un tiempo expliqué cómo utilizar los backports en Debian. Más adelante demostré cómo dar prioridad a los backports, y en dicho artículo decía textualmente:

    "...los backports son paquetes provenientes de testing compilados en un entorno estable... Esto significa que no son paquetes estables."

    "Habiendo aclarado nuevamente la naturaleza de los backports, la conclusión es que esta configuración no es 100% recomendable para servidores..."

    Bueno, este es el caso típico de "haz lo que yo digo, mas no lo que yo hago". Por dar prioridad a los backports y blacklistear "systemd*", terminé con un buen problema de dependencias y el sistema imposible de actualizar. Crónica de una muerte anunciada...

    En este artículo voy a demostrar cómo diagnosticar y resolver problemas de dependencias cuando se utilizan repositorios inestables de Debian y derivados.