¿Cómo comparar las claves de arranque seguras almacenadas en la base de datos del firmware de la placa base con los archivos .efi firmados?

¿Cómo comparar las claves de arranque seguras almacenadas en la base de datos del firmware de la placa base con los archivos .efi firmados?

Es muy fácil habilitar el arranque seguro en una máquina virtual, pero estoy luchando por hacer lo mismo con OpenSUSE en mi computadora antigua de 2012 que se niega a arrancar en modo de arranque seguro incluso en la configuración estándar (parece que con las claves de Microsoft). . Me gustaría solucionar la parte más crítica: ¿Coinciden las claves entre el firmware y la cuña? ¿Cómo comprobar eso?

Respuesta1

¿Qué es el arranque seguro?

CitandoPartícula.io:

...El arranque seguro se refiere al proceso de autenticar el firmware y el sistema operativo de un dispositivo con una clave criptográfica segura conocida colocada en el dispositivo en el momento de su fabricación. Esta autenticación ocurre cada vez que se inicia el dispositivo para validar que el firmware o el código que se está cargando es la versión legítima que colocó allí quien lo produjo.

La cita anterior y el enlace se refieren a dispositivos IoT. La cita sigue siendo válida para las PC si las consideramos "cosas". En el caso de la pregunta del OP, no importa la antigüedad del dispositivo, ya que la premisa de la cita era la misma en 2012 que ahora. Voy a comenzar el resto de esta respuesta de solución de problemas asumiendo que el repositorio de claves debe "restablecerse", lo cual el OP ya hizo, pero lo hago para beneficio de futuros visitantes.

Pasos detallados

Generemos una lista numerada de lo que debemos hacer para dividir esta tarea en partes más pequeñas:

  1. Leer sobreCómo funciona Secure Boot en Linux con respecto a SuSE. Nota: La implementación en ese enlace en 2012 es más o menos cómo todas las distribuciones implementaron el arranque seguro.
    • En aras de la simplicidad, voy a publicar la "meollo" de ese artículo (para aquellos de ustedes que leen por encima), ya que este es el problema fundamental que tiene el OP): Diagrama de flujo para SecureBoot
  2. Restablezca el firmware de su Mac a los valores predeterminados de fábricarealizar un reinicio del cochecito
  3. Utilice estos pasosdescrito por Roderick Smith
    • El paso 3 puede simplificarse si OpenSuSE Live ISO incluye el programa MokManager o el programa MokUtil.
  4. Registre la clave que desee en la base de datos MOK.
    • Opcional: si sigue los pasos anteriores (elementos 3 y 4), terminará registrando tanto la clave rEFInd como la clave SuSE. Si planea utilizar OSX y OpenSuSE con arranque dual, le recomiendo que utilice este Administrador de arranque. Si solo planea usar OpenSuSE, solo necesita registrar ese certificado.
  5. Ahora debería shimconocer las nuevas claves y pasar correctamente el proceso a Grub2, y Grub 2 iniciará OpenSuSE.

Qué hacer si los pasos anteriores fallan

Consulte la sección de solución de problemas deInstalar openSUSE en una Mac. Como una corazonada, citando nuevamente a Roderick Smith:

Algunas implementaciones de EFI (en su mayoría anteriores a 2014) hacen un mal trabajo al respetar las opciones de arranque configuradas a través de efibootmgr de Linux u otras herramientas. También es posible que no tenga acceso a dichas utilidades, por ejemplo, si debe instalar rEFInd en Windows. En tales casos, es posible que necesite cambiar el nombre del cargador de arranque para que EFI lo vea como el cargador de arranque predeterminado. rEFInd debería entonces arrancar cuando su NVRAM carezca de información sobre cargadores de arranque específicos a utilizar.

shim<arch>.efiEn el caso anterior, cambie el nombre del archivo de OpenSuSE a boot<arch>.efiy colóquelo en el BOOTdirectorio (si no hay BOOTun directorio, colóquelo en la raíz) donde archestá x32o x64 Si este método funciona, el firmware del OP solo admite el arranque desde un archivo. Ver:Opciones de nombres alternativos.

Por cierto, correcciones como esta son necesarias incluso en sistemas más nuevos. Ver:Actualice la NVRAM para que se ejecute shimx64.efi en lugar de grubx64.efi en el sistema Debian para un arranque seguro. Siento el dolor del OP a este respecto.

información relacionada