Hace un año que observamos los parches de bloqueo del kernel; eso se debe a que las cosas han estado bastante tranquilas en ese frente ya que hubo una fuerte y discordante disputa sobre ellos en ese entonces. Pero Matthew Garrett ha estado publicando nuevas versiones en los últimos dos meses; Parecería que los cambios que se han hecho podrían ser suficientes para sofocar las llamas y, quizás, incluso permitir que se fusionen en la rama principal del código de Linux.
Comentarios
Mando esto porque he estado dándole vueltas unos buenos ratos al porqué Systemtap no me funcionaba pese a que firmaba el módulo generado (https://sourceware.org/systemtap/wiki/SecureBoot). Y era por esto.
Por lo visto Canonical aplica estos parches al kernel que distribuye con Ubuntu, que actualmente activan el bloqueo de forma automática si el sistema arranca con Secureboot activado. Y además el atajo Sysrq+x está desactivado por defecto (hay que cambiar kernel.sysrq en /etc/sysctl.conf con valor 1). Ese atajo permite desactivar el bloqueo (kernel lockdown) durante la sesión, permitiendo hacer uso de Systemtap. En dmesg aparecen un par de mensajitos una vez se desactiva:
sysrq: SysRq : Disabling Secure Boot restrictions
Lifting lockdown
El problema concreto es que Systemtap necesita acceso al debugfs para leer la entrada del módulo generado por Systemtap. Y el bloqueo lo impide.
Muy gracioso todo.
No sé si Systemtap está haciendo un uso correcto del debugfs, ya que en principio el módulo insertado debería encargarse de todo y el acceso al debugfs debería ser innecesario. El debugfs está para depurar.