Navegar por las API del kernel Linux puede llevar mucho tiempo, por lo que el gurú de Linux, Vegard Nossum, creó una hoja informativa (cheat sheet) muy útil para ahorrar tiempo para ayudar a atravesar las primitivas de concurrencia del kernel Linux (PDF 114 KiB).

Este libro es una guía de programación de módulos del kernel Linux que se puede distribuir libremente. Inicialmente se centró en la versión 2.2 del kernel hasta que su autor principal, Ori Pomerantz, dejó de tener tiempo para mantenerlo actualizado, con lo que sus mantenedores han cambiado a lo largo de los años hasta que, finalmente, Jim Huang se hizo cargo de su actualización para cubrir hasta las versiones 5.x del kernel Linux.

A raíz de la publicación de la noticia del lanzamiento del Kernel 4.12 de Linux, el cual trae por primera vez activada por defecto la característica KASLR, y casi simultáneamente la publicación de otra noticia sobre la implementación de una característica llamada KARL en OpenBSD, me ha parecido que sería interesante aclarar las diferencias entre estas técnicas de seguridad, pues pienso que la combinación de ambas va a ser muy importante de cara al futuro de la seguridad de los sistemas, pues van a impedir explotar vulnerabilidades relacionadas con la corrupción de memoria (buffer overflow). Pero antes de entrar a detallar las características de KASLR y KARL, echemos un vistazo ASLR.

Hoy vamos a empezar una serie de entradas acerca de cómo se compila el kernel de Linux para entender mejor cómo funciona un ordenador. Y empezaremos con teoría… con mucha teoría. En esta entrada veremos, para empezar, las tareas básicas de un kernel. Comencemos…

En este pequeño documento se describe el estilo de código preferido para desarrollar el kernel Linux. El estilo de código es muy personal y no se va a forzar ningún estilo en este documento, pero escribir siguiendo determinada forma hace que el código sea mucho más mantenible. Pero, antes de nada, sugiero descargar e imprimir una copia del estilo de código GNU para NO leerla nunca. Quémala. Es un gran gesto simbólico. Y a continuación, las normas del estilo de codificación del kernel Linux.

En la primera parte de esta serie (www.meneame.net/m/SysDevs/portando-linux-nueva-arquitectura-parte-1-ba ) hemos sentado las bases para portar Linux a una nueva arquitectura de procesador explicando los pasos preliminares (sin llegar a escribir ningún código fuente). Este artículo continúa desde allí profundizando en el código de arranque, lo que incluye desde el código necesario para arrancar Linux hasta la creación del primer hilo del kernel.

Como supongo que sabrás, nuestros programas interaccionan con el kernel mediante un mecanismo especial conocido como llamadas al sistema (system calls o syscalls). Si has escrito al menos un programa en C, sabrás que antes de hacer cualquier lectura y/o escritura a un archivo es necesario abrirlo. Para ello se utiliza la función ‘open’. En este caso es una función de la librería estándar (libc) y es ella la que se encarga de realizar la llamada al sistema por nosotros.

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.

Unos meses después de que comenzara mi contrato con Haiku, Inc., reescribí la implementación de las variables de condición del kernel de Haiku (a diferencia de nuestras variables de condición del espacio de usuario, que son de POSIX). Como esta nueva implementación se ha ejecutado en Haiku durante más de un año. y se envió en la última versión sin signos de problemas restantes, pensé que ya era hora de profundizar en la API, su historial de implementación y el diseño de la nueva implementación que escribí.

Investigadores de Google Project Zero han hecho pública una vulnerabilidad en macOS, después de que Apple no haya liberado un parche en los 90 días previos a la publicación. Descubierta por el investigador Jann Horn y demostrada por Ian Beer, la vulnerabilidad reside en la forma que el kernel de macOS, XNU, permite a un atacante manipular el sistema de ficheros sin informar al sistema operativo.

En junio de 2020 anunciamos que el microkernel seL4 fue el primer kernel de sistema operativo del mundo con prueba de corrección de implementación verificada por máquina, también verificada para la arquitectura RV64, lo que lo convierte en el primer sistema operativo verificado formalmente para RISC-V. Ahora nos complace anunciar que esta verificación se ha extendido al código binario ejecutable, lo que significa que se ha demostrado que el código máquina que se ejecuta en el procesador es correcto. // Relacionada: El microkernel seL4 ha sido verificado formalmente para procesadores RISC-V.

‘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.

Aunque un port simple puede contar con tan sólo 4000 líneas de código —exactamente 3775 son las del procesador Hitachi 8/300 (sin MMU) recientemente introducidas en Linux 4.2-rc1—, conseguir que el kernel de Linux se ejecute en una nueva arquitectura de procesador es un proceso difícil. Peor aún, no hay mucha documentación disponible que describa dicho proceso de portabilidad. El objetivo de esta serie de artículos es proporcionar una visión general del procedimiento de portar el kernel de Linux a una nueva arquitectura de procesador.

El artículo describe cómo funcionan las señales en Linux y cómo se manejan usando el API de POSIX. Se cubrirán las funciones en todos los sistemas modernos de Linux, cosa que también se puede aplicar a la mayoría de los sistemas POSIX (a menos que se indique lo contrario). Para seguir bien el artículo se recomienda tener un conocimiento básico acerca de señales.

Recientemente anunciamos Bash en Ubuntu en Windows que permite binarios Linux ELF64 en Windows via el Windows Subsystem for Linux (WSL). Este subsistema fue creado por el equipo Microsoft Windows Kernel y ha generado mucho revuelo. Una de las preguntas más frecuentes que recibimos es la diferencia que hay con respecto a una máquina virtual. En este primer post de una serie de varios, explicaremos lo básico de WSL que responda esas y otras preguntas. En futuros posts entraremos al detalle de cada componente aquí presentado.