googleprojectzero/maccconcToolkit para explorar condiciones de carrera del kernel de Linux utilizando trazas de KCOV: visores GUI y de terminal para ejecución concurrente y acceso a memoria, además de pruebas automáticas de ordenamiento A-B-A.
Este es un conjunto de herramientas para explorar condiciones de carrera del kernel de Linux y para la depuración general del kernel.
Véase también la publicación del blog de anuncio https://projectzero.google/2026/09/maccconc-race-condition.html.
Actualmente hay tres herramientas:
Este no es un producto oficialmente compatible con Google. Este proyecto no es elegible para el Google Open Source Software Vulnerability Rewards Program.
Primero, obtenga una versión de LLVM que incluya el commit dc5c6d008f48; es decir, ya sea una compilación desde HEAD, en lugar de desde una rama de versión, o una compilación en la versión >=23. Tales compilaciones están, por ejemplo, disponibles en https://apt.llvm.org/ . Si es un googler, consulte http://go/maccconc-kernel-build-notes .
Obtenga un árbol del kernel con los parches requeridos desde https://github.com/thejh/linux , rama kcov-tracing-full.
Al configurar y compilar el kernel, establezca las variables de make
CC / LLVM / LLVM_PREFIX como se documenta en
https://docs.kernel.org/kbuild/llvm.html para asegurarse de que se utilice la cadena de herramientas LLVM correcta.
Establezca esta variable de entorno para obtener información más clara sobre los bloques básicos ejecutados (para la GUI) y evitar pilas de llamadas confusas debido a la optimización de llamadas de cola:
export KCFLAGS="-fno-optimize-sibling-calls -mllvm -sanitizer-coverage-prune-blocks=false"
Configure el kernel como de costumbre; podría ser útil comenzar desde
make [...] kvm_guest.config si no parte de una configuración existente.
Asegúrese de que los siguientes indicadores de configuración del kernel estén establecidos (por ejemplo, a través de la interfaz de configuración ncurses make [...] nconfig o pegándolos al final de .config):
# for core functionality
CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_KASAN=y
CONFIG_KASAN_OUTLINE=y
CONFIG_KCOV=y
CONFIG_KCOV_EXT_RECORDS=y
CONFIG_KCOV_MEMORY=y
CONFIG_KALLSYMS_ALL=y
# to give the GUI information about source lines and inlining
CONFIG_DEBUG_INFO_DWARF5=y
# for communicating with the GUI
CONFIG_VSOCKETS=y
CONFIG_VIRTIO_VSOCKETS=y
CONFIG_VIRTIO_PCI=y
# for maximizing the potential for race conditions
CONFIG_PREEMPT=y
# for making virtual addresses at runtime the same as in vmlinux
CONFIG_RANDOMIZE_BASE=n
# needed for several samples
CONFIG_TMPFS=y
También puede habilitar lo siguiente si desea probar condiciones de carrera que involucren RCU, pero tenga en cuenta que esto causará una gran ralentización y actualmente solo funciona correctamente si usa la GUI.
CONFIG_RCU_EXPERT=y
CONFIG_RCU_STRICT_GRACE_PERIOD=y
Asegúrese de que cualquier característica del kernel que desee probar esté compilada dentro del kernel, no como módulos.
Se recomienda compilar las herramientas de espacio de usuario en la máquina anfitriona; especialmente la GUI, que está diseñada para ejecutarse en el host, no en el invitado.
Instale git y las dependencias de compilación; para Debian:
sudo apt install git build-essential pkg-config libcapstone-dev libdw-dev libglfw3-dev
Después de clonar este repositorio, descargue los submódulos con:
git submodule update --init --recursive
Compile con make.
Puede arrancar el kernel compilado en una VM QEMU normal si habilita los indicadores de configuración del kernel requeridos y usa una imagen de disco con una distribución de Linux, o algo similar; pero el enfoque recomendado es instalar kvmtool así:
git clone https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
cd kvmtool
make
make install
Luego puede arrancar el kernel compilado de la siguiente manera (asumiendo que $HOME/bin está en su $PATH):
lkvm run --kernel [path to kernel tree]/arch/x86/boot/bzImage --vsock 5 --console virtio
Esto le dará un shell en un entorno donde una vista de solo lectura del sistema de archivos del host está montada en /host, con un rootfs mínimo que consiste principalmente en enlaces simbólicos a este sistema de archivos del host para /bin, /lib, /usr y demás. Tanto / como /host son sistemas de archivos 9p.
Monte manualmente debugfs y tmpfs en el invitado después de cada arranque:
sh-5.3# mount -t debugfs none /sys/kernel/debug
sh-5.3# mount -t tmpfs none /tmp
sh-5.3#
Los casos de prueba son código C que define cuatro funciones:
void test_setup(void) { [...] }
void test_thread1(void) { [...] }
void test_thread2(void) { [...] }
void test_end(void) { [...] }
Para cada ejecución del caso de prueba, test_setup() se ejecutará primero; luego test_thread1() y test_thread2() se ejecutarán en paralelo; y finalmente, test_end() se ejecutará.
Los casos de prueba deben compilarse como bibliotecas compartidas, así:
$ cc -shared -o [name].so [name].c -fPIC
Los casos de prueba de ejemplo en la carpeta testcase/ también se pueden compilar mediante make, así:
$ make testcase/demo-dup-vs-close.so
cc -shared -o testcase/demo-dup-vs-close.so testcase/demo-dup-vs-close.c -Wall
La herramienta kcov-autorace puede explorar automáticamente ordenamientos de ejecución A-B-A. Los ordenamientos A-B-A son aquellos en los que el hilo A se ejecuta hasta un punto, luego el hilo B se ejecuta por completo, y después el hilo A finaliza su ejecución.
Después de compilar un caso de prueba en el host, puede ejecutarlo en el invitado usando el asistente kcov-autorace. Por ejemplo:
sh-5.3# cd /host/{path to checkout on the host}
sh-5.3# ./kcov-autorace testcase/demo-dup-vs-close.so
loading kallsyms
RCU state (excluded): base=ffffffff82770100 len=500
loading testcase
initializing kcov
collecting A-B coverage
dup(5) = 6 (success)
testing candidates
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = 5 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
stats: injection-failed:0 wait-timeout:7 reordered:4
sh-5.3#
Esto muestra que existe un ordenamiento A-B-A de close(5) y dup(5) que da como resultado que dup(5) devuelva 5.
Tenga en cuenta que kcov-autorace y las otras herramientas usan un tiempo de espera de giro codificado SPIN_LIMIT.
La herramienta kcov-terminal se puede usar para ejecutar un caso de prueba con restricciones de ordenamiento especificadas manualmente. Estas no especifican un ordenamiento completo; en su lugar, son un conjunto de reglas "A debe ocurrir antes que B".
Esta herramienta se usa en el invitado, de manera similar a kcov-autorace.
Ejemplo de uso con el caso de prueba demo-inode-attr-change para ejecutar con restricciones de ordenamiento que demuestran que la lectura de UID y GID por fstat() no es atómica con respecto a fchown():
sh-5.3# ./kcov-terminal testcase/demo-inode-attr-change.so
uid=0 gid=0
===== filtered to interference set, no RCU core =====
LEGEND:
type: R=read W=write M=modify(read+write) F=free A=atomic