El laboratorio de investigación 360 Netlab anunció la identificación de un nuevo malware para Linux, con nombre en código RotaJakiro, que incluye una puerta trasera que permite controlar el sistema. Los atacantes podrían haber instalado software malicioso después de explotar vulnerabilidades no reparadas en el sistema o adivinar contraseñas débiles. El backdoor se descubrió durante el análisis del tráfico sospechoso de uno de los procesos del sistema identificados durante el análisis de la estructura de una botnet usada para ataques DDoS.

Con la nueva versión 221 de systemd hemos declarando la API sd-bus de systemd como estable. sd-bus es nuestra biblioteca mínima de D-Bus que envuelve el clásico socket-D-Bus y kdbus. La biblioteca ha sido parte de systemd desde hace tiempo (aunque sólo para uso interno) ya que quería tener la libertad de poder hacer cambios en la API sin afectar al resto de usuarios de esta biblioteca. Sin embargo, ahora estamos seguros de que es un API estable por lo que estará disponible a partir de la versión 221 de systemd.

Cuando empezamos a trabajar en systemd, lo construimos alrededor de un bucle de eventos escrito a mano usando epoll en Linux. Pero cuanto más crecía nuestro proyecto, más nos dimos cuenta de las limitaciones del uso de epoll. Algunas de estas limitaciones son que usaba demasiados descriptores de fichero, que el gestionar el orden de los eventos era tedioso o que para cada programa que usaba systemd añadíamos el mismo código duplicándolo. Así que, a partir de ahí para solucionar estos problemas comenzamos a trabajar en sd-bus.

Linux ha sido compatible con Full Disk Encryption (FDE) y tecnologías como UEFI SecureBoot y TPM durante mucho tiempo. Sin embargo, la forma en que están configurados por la mayoría de las distribuciones no es tan segura como debería ser y, francamente, de alguna manera bastante extraña. De hecho, en este momento tus datos probablemente estén más seguros si se almacenan en dispositivos ChromeOS, Android, Windows o MacOS actuales que en las distribuciones típicas de Linux.

Limitar los procesos de usuario es importante para el funcionamiento estable de un sistema operativo como Linux. Para limitar dichos procesos de usuario sólo se tiene que poner la configuración correcta en el archivo /etc/security/limits.conf. Pero comencemos por entender cómo está estructurado este archivo y cuáles son sus opciones principales.

Este es el segundo artículo de la serie sobre comunicación entre procesos (IPC) en Linux. El primer artículo se centró en IPC a través del almacenamiento compartido: archivos y memoria compartida. Este artículo se dirige a las tuberías (pipes), canales que conectan procesos para la comunicación con un punto de escritura para escribir bytes y otro punto de lectura para leer estos bytes en orden FIFO (primero en entrar, primero en salir), y colas de mensajes, donde se añaden mensajes a colas FIFO que luego se procesan.

‘linux-inject’ es una utilidad para Linux que inyecta una librería .so dentro de un proceso en ejecución. Funciona de forma similar a como lo hace LD_PRELOAD pero, como se ha comentado, ‘linux-inject’ inserta el código mientras el proceso está corriendo. Veamos un ejemplo de su funcionamiento.

Supongamos que hay un programa ejecutándose en su sistema en el que no confía del todo. Tal vez es un programa presentado por un alumno a un sistema de calificación automatizado. O tal vez es un modelo de dispositivo QEMU que se ejecuta en un dominio de control Xen ('dominio 0' o 'dom0') y quiere asegurarse de que incluso si un atacante de una máquina virtual deshonesta se las arregla para hacerse cargo del proceso QEMU no puedan hacer más daño. Hay muchas cosas que quiere hacer en cuanto a restringir su capacidad de hacer travesuras, pero hay algo que probablemente quieras hacer: matar el proceso de manera confiable cuando se crea necesario.

Una CPU está inactiva si no hay tareas a ejecutar. El kernel Linux tiene varias clases de prioridad interna de procesos; una de ellas es la clase especial de procesos inactivos. Si no hay tareas a ejecutar en una CPU determinada en cualquiera de sus clases la CPU se considera inactiva. Si el hardware no soporta “desactivar” las CPU entonces la CPU tiene que ejecutar instrucciones inútiles hasta que sea necesaria para trabajo real. Sin embargo, este es un uso muy ineficiente de la electricidad, por lo que muchas CPU soportan estados de bajo consumo. Pero entrar en esos estados no es gratis.

En esta entrada se muestra cómo se puede minimizar la sobrecarga de cambios de contexto en el kernel de un sistema operativo a través del mayor uso de llamadas al sistema asíncronas y primitivas de comunicación entre procesos.

‘htop’ es un monitor de procesos interactivo en modo consola. Si se coge el famoso ‘top’ y se le añaden esteroides, tenemos ‘htop’. Esta herramienta muestra un montón de información acerca de los procesos que se están ejecutando. Además, es totalmente funcional sólo con el teclado. En esta entrada veremos qué es cada parte de ‘htop’ y qué significa.

Este es el primer artículo de una serie sobre comunicación entre procesos (IPC) en Linux. La serie utiliza ejemplos de código en C para aclarar los siguientes mecanismos de IPC: archivos compartidos; memoria compartida (con semáforos); pipes (con nombre y sin nombre); colas de mensajes; sockets; y señales. Este artículo revisa algunos conceptos básicos antes de continuar. Los dos primeros de estos mecanismos: archivos compartidos y memoria compartida.

Comparación entre dos métodos de comunicación entre procesos en Linux: el primero y más antiguo AF_UNIX y el segundo y más moderno (todavía no incluido en el kernel) kdbus.

Warp processing is the process of dynamically converting a typical software instructions binary into an FPGA circuit binary for massive speedups ("warp speed"). FPGAs are a relatively new type of IC that supports highly-parallel computations from the arithmetic up to the process level, at the cost of larger size and slower clock frequency. While some applications exhibit no speedup on FPGAs (or even slowdown), other highly-parallelizable applications, such as image processing, encryption, encoding, video/audio processing, mathematical-based simulations, and much more, may exhibit 2x, 10x, 100x -- even 1000x speedups compared even to fast microprocessors.

Cualquiera que haya tenido una clase de arquitectura de computadores avanzada ha oído hablar del CDC6600, el que fue el ordenador más rápido del mundo desde 1964 hasta 1969. Esta fue la máquina que puso a Seymour Cray en el mapa como arquitecto de supercomputadoras, aunque el arquitecto principal fue James Thornton. Uno de los conceptos de arquitectura de computadores, que luego fue usado en arquitecturas RISC, por el que el CDC6600 es conocido fue la introducción del scoreboard, que, junto al algoritmo de Tomasulo, fueron unos de los primeros conceptos de ejecución de instrucciones fuera de orden.

La inicialización del sistema es una de las áreas de nicho que pocas personas analizan. Los detalles exactos varían considerablemente entre diferentes plataformas, firmwares, arquitecturas de CPU y sistemas operativos, lo que dificulta aprenderlos todos. Por lo general, si algo no funciona correctamente durante las primeras etapas del inicio del sistema o si el sistema operativo no se inicia, rara vez tiene algo que ver con el código responsable del inicio. La mayoría de las veces, se debe a otros factores, como el medio de arranque o la configuración del BIOS.