OpenCore y UEFI Secure Boot con WSL

El firmware UEFI de las placas base tiene la capacidad de arranque seguro de forma que sólo se permiten los archivos del boot loader firmados digitalmente con las claves que están integradas en el firmware. Con UEFI Secure Boot habilitado:
– Windows puede arrancar ya que los firmware incorporan certificados de Microsoft (a veces también certificados del fabricante de la placa base)
– macOS no puede arrancar; es necesario un sistema Linux en el que generar las claves y firmar con ellas los archivos de OpenCore, este es el motivo por el que actualmente arrancamos OpenCore con UEFI Secure Boot deshabilitado.

Este texto se basa en los artículos de:

Los artículos de sakaki y de Ubuntu plantean cómo arrancar Linux con UEFI Secure Boot activado pero khronokernel y profzei se refieren específicamente a OpenCore y macOS. Los 4 artículos coinciden en la necesidad de hacerlo desde un sistema Linux ya que las herramientas requeridas no existen para macOS. El sistema Linux necesario para firmar los archivos de OpenCore puede suponer un inconveniente significativo por el trabajo que conlleva su instalación y configuración (bien en disco independiente o en máquina virtual).
Una vez en Linux, todo se hace desde Terminal por lo que gran parte del sistema instalado realmente no hace falta.
Esta tarea se puede simplificar gracias a una infraestructura no demasiado utilizada que existe en Windows 10 (compilación 18917 o posterior) y Windows 11: Windows Subsystem for Linux (WSL), gracias a la cual podemos arrancar una imagen genuina de Ubuntu proporcionada por Canonical. Esto posibilita la ejecución de comandos de forma nativa en un terminal de Bash dentro de un entorno Windows que se comporta como Linux.

En este texto se propone la activación de UEFI Secure Boot en OpenCore desde un sistema Windows 11 con WSL instalado, sin tener que recurrir a la instalación y configuración de un sistema Linux completo por separado o en máquina virtual. Sigue siendo necesario un cierto conocimiento de los comandos básicos de Linux pero se requieren menos tiempo y esfuerzo que con la opción nativa.

Nota: en la tienda de aplicaciones de Microsoft hay otras distribuciones Linux disponibles para instalar en WSL, incluso es posible tener más de una y pueden ser gestionadas con la aplicación WSL Manager.

Instalar WSL desde línea de comandos (instala Ubuntu de forma predeterminada)

Abrir PowerShell como Administrador >> ejecutar el comando wsl –install

PS C:/Users/miliuco> wsl --install
Instalando: Plataforma de máquina virtual
Se ha instalado Plataforma de máquina virtual.
Instalando: Subsistema de Windows para Linux
Se ha instalado Subsistema de Windows para Linux.
Descargando: Kernel de WSL
Instalando: Kernel de WSL
Se ha instalado Kernel de WSL.
Descargando: Soporte técnico de la aplicación de GUI
Instalando: Soporte técnico de la aplicación de GUI
Se ha instalado Soporte técnico de la aplicación de GUI .
Descargando: Ubuntu
La operación solicitada se realizó correctamente. Los cambios se aplicarán una vez que se reinicie el sistema.

Al finalizar solicita la creación de un nombre de usuario y una contraseña (no tienen relación con los que utilizas en Windows). Esta será la cuenta predeterminada e iniciará la sesión automáticamente en la carpeta home. Es cuenta de administrador y puede ejecutar comandos con sudo.

WSL arranca desde el icono Ubuntu del menú de aplicaciones o escribiendo ubuntu en la ventana de línea de comandos. Se muestra una ventana de Terminal de Bash con el prompt en nuestra carpeta de usuario.
Los discos de Windows son accesibles en la ruta /mnt/c, /mnt/d y así sucesivamente. El sistema Limux es accesible desde Explorador de Windows >> Linux. No se recomienda modificar elementos de Ubuntu desde el explorador de Windows, es preferible hacerlo desde dentro de WSL.

Si en algún momento olvidas la contraseña de Linux >> abre PowerShell >> wsl -u root (abre Ubuntu en el directorio del usuario Windows) >> passwd >> solicita una contraseña nueva >> exit.

Nota: también puedes instalar Ubuntu desde Microsoft Store con la ventaja de que se instala para todos los usuarios, en cambio desde PowerShell se instala sólo para el usuario actual.

Instalar las herramientas

En la ventana de Terminal de Ubuntu:

  • sudo apt update && sudo apt upgrade (para actualizar repositorios de paquetes de instalación)
  • sudo apt-get install unzip (unzip no se instala por defecto con Ubuntu de WSL, la utilidad zip en cambio si está instalada)
  • sudo apt-get install sbsigntool (utilidad de firma digital para UEFI Secure Boot)
  • sudo apt-get install efitools (herramientas para gestionar variables de UEFI Secure Boot)

La herramienta openssl también es necesaria pero ya está instalada en Ubuntu.

Si queremos ver las utilidades ya instaladas en Ubuntu podemos usar el comando:
sudo apt list –installed

Crear las claves para incluir en el firmware y firmar OpenCore

Crear una carpeta de trabajo:

mkdir efikeys
cd efikeys

Crear PK (Platform Key):

openssl req -new -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes -subj "/CN=NAME PK/" -keyout PK.key -out PK.pem

Crear KEK (Key Exchange Key):

openssl req -new -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes -subj "/CN=NAME KEK/" -keyout KEK.key -out KEK.pem

Crear ISK (Initial Supplier Key):

openssl req -new -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes -subj "/CN=NAME ISK/" -keyout ISK.key -out ISK.pem

Nota: reemplaza NAME por algo característico que te ayude a reconocerlas cuando las consultes desde el menú de UEFI, por ejemplo CLAVES2021.

Permisos correctos para los archivos de claves:

chmod 0600 *.key

Descargar los certificados de Microsoft para arrancar Windows:
Microsoft Windows Production CA 2011
Microsoft UEFI driver signing CA key

Copiar los certificados de Windows a la carpeta de trabajo:

cp /mnt/c/Users/yo/Downloads/MicCorUEFCA2011_2011-06-27.crt /home/yo/efikeys/
cp /mnt/c/Users/yo/Downloads/MicWinProPCA2011_2011-10-19.crt /home/yo/efikeys/

Firmar digitalmente los certificados de Microsoft:

openssl x509 -in MicWinProPCA2011_2011-10-19.crt -inform DER -out MicWinProPCA2011_2011-10-19.pem -outform PEM
openssl x509 -in MicCorUEFCA2011_2011-06-27.crt -inform DER -out MicCorUEFCA2011_2011-06-27.pem -outform PEM

Convertir los archivos PEM al formato ESL apto para UEFI Secure Boot:

cert-to-efi-sig-list -g $(uuidgen) PK.pem PK.esl
cert-to-efi-sig-list -g $(uuidgen) KEK.pem KEK.esl
cert-to-efi-sig-list -g $(uuidgen) ISK.pem ISK.esl
cert-to-efi-sig-list -g $(uuidgen) MicWinProPCA2011_2011-10-19.pem MicWinProPCA2011_2011-10-19.esl
cert-to-efi-sig-list -g $(uuidgen) MicCorUEFCA2011_2011-06-27.pem MicCorUEFCA2011_2011-06-27.esl

Crear la base de datos de firmas permitidas incluyendo los certificados de Microsoft firmados:

cat ISK.esl MicWinProPCA2011_2011-10-19.esl MicCorUEFCA2011_2011-06-27.esl > db.esl

Firmar digitalmente los archivos ESL:

//(PK se firma con ella misma)
sign-efi-sig-list -k PK.key -c PK.pem PK PK.esl PK.auth
Timestamp is 2021-11-2 00:05:40
Authentication Payload size 887
Signature of size 1221
Signature at: 40
//(KEK se firma con PK)
sign-efi-sig-list -k PK.key -c PK.pem KEK KEK.esl KEK.auth
Timestamp is 2021-11-2 00:05:47
Authentication Payload size 891
Signature of size 1221
Signature at: 40
//(la base de datos se firma con KEK).
sign-efi-sig-list -k KEK.key -c KEK.pem db db.esl db.auth
Timestamp is 2021-11-2 00:05:52
Authentication Payload size 4042
Signature of size 1224
Signature at: 40

Los archivos .auth (PK.auth, kek.auth y db.auth) serán utilizados para integrar nuestras firmas en el firmware. Copia estos archivos a una carpeta fuera de Ubuntu para que sean accesibles desde Windows.
Los archivos ISK.key y ISK.pem serán utilizados para firmar los archivos de OpenCore.

Firmar los archivos de OpenCore

Es necesario firmar los archivos con extensión .efi: OpenCore.efi, BOOTx64.efi y contenido de las carpetas Drivers y Tools.

Crear directorio de trabajo:

mkdir oc
cd oc

Copiar ISK.key y ISK.pem a la carpeta oc:

cp ISK.key ISK.pem oc
cd oc

El usuario profzei ha creado un script sign_opencore.sh que automatiza este proceso: descarga y descomprime OpenCore versión actual (0.8.4 en el momento de escribir este texto), descarga HFSPlus.efi, comprueba las claves ISK, firma digitalmente los archivos y los copia a la carpeta Signed. El script ha de estar en la carpeta oc junto a ISK.key y ISK.pem.
Copia este texto en un editor de texto y guárdalo con el nombre sign_opencore.sh (puedes hacerlo en Windows):

#!/bin/bash
# Copyright (c) 2021 by profzei
# Licensed under the terms of the GPL v3

LINK=$1
# https://github.com/acidanthera/OpenCorePkg/releases/download/0.8.4/OpenCore-0.8.4-RELEASE.zip
VERSION=$2
# 0.8.4

mkdir Signed
mkdir Signed/Drivers
mkdir Signed/Tools

# Download and unzip OpenCore
wget $LINK
unzip "OpenCore-${VERSION}-RELEASE.zip" "X64/*" -d "./Downloaded"
rm "OpenCore-${VERSION}-RELEASE.zip"

# Download HfsPlus
wget https://github.com/acidanthera/OcBinaryData/raw/master/Drivers/HfsPlus.efi -O ./Downloaded/HfsPlus.efi

if [ -f "./ISK.key" ]; then
    echo "ISK.key was decrypted successfully"
fi

if [ -f "./ISK.pem" ]; then
    echo "ISK.pem was decrypted successfully"
fi

# Sign drivers
sbsign --key ISK.key --cert ISK.pem --output ./Signed/BOOTx64.efi ./Downloaded/X64/EFI/BOOT/BOOTx64.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/OpenCore.efi ./Downloaded/X64/EFI/OC/OpenCore.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/Drivers/OpenRuntime.efi ./Downloaded/X64/EFI/OC/Drivers/OpenRuntime.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/Drivers/OpenCanopy.efi ./Downloaded/X64/EFI/OC/Drivers/OpenCanopy.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/Drivers/AudioDxe.efi ./Downloaded/X64/EFI/OC/Drivers/AudioDxe.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/Drivers/HfsPlus.efi ./Downloaded/HfsPlus.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/Tools/OpenShell.efi ./Downloaded/X64/EFI/OC/Tools/OpenShell.efi

# Clean 
rm -rf Downloaded
echo "Cleaned..."

Copia el script a la carpeta oc:

cp /mnt/c/Users/yo/Downloads/sign_opencore.sh /home/yo/efikeys/oc

Este script se ejecuta con 2 parámetros: el sitio de descarga de OpenCore y el número de versión. Por ejemplo, con la versión 0.8.4 (en una sola línea):

sh ./sign_opencore.sh https://github.com/acidanthera/OpenCorePkg/releases/download/0.8.4/OpenCore-0.8.4-RELEASE.zip 0.8.4

Al finalizar tendremos en la carpeta Signed los archivos .efi de OpenCore firmados digitalmente con nuestras propias claves. Copia la carpeta Signed a una localización (fuera de Ubuntu) que sea accesible desde Windows y/o macOS y pon los archivos .efi firmados en la carpeta EFI de OpenCore reemplazando a los del mismo nombre.

cp -r /home/yo/efikeys/ /mnt/c/Users/yo/Downloads/

Nota: el usuario Lukakeiton tieneun script que automatiza el proceso unificando todos los pasos ampliando la funcionalidad del script de profzei:
1. instala las herramientas necesarias
2. genera las claves
3. descarga OpenCore y firma los archivos .efi.
Además pone al día los orígenes de actualización de Ubuntu antes de comprobar si tenemos las herramientas instaladas.
Según el propio autor: «Este script sólo necesita como parámetro de entrada la versión de OpenCore con el siguiente formato X.Y.Z. Ejemplo: sh ./sign_oc.sh 0.8.4 crea una carpeta llamada oc en la carpeta de descargas de Windows con todos los archivos de la versión 0.8.4 de OpenCore ya firmados».
Está disponible en su sitio de GitHub.

Incluir los archivos en el firmware

El paso final es introducir en el firmware los archivos de firma reemplazando las variables existentes:

  • db.auth >> Authorized Signatures
  • kek.auth >> KEK (Key Exchange Keys)
  • pk.auth >> PK (Platform key).

Esto puede ser realizado de 2 maneras: desde el menú de configuración de la placa base o con la herramienta especializada KeyTool.

  1. BIOS

En la sección Secure Boot suele haber opciones para restaurar las claves que vienen de fábrica (borrar lo que hayamos configurado y recuperar la lista original de firmas autorizadas, Microsoft y Gigabyte) o para editar las variables por separado (se pueden exportar, actualizar, eliminar o mostrar detalles).
En mi placa base (Z390 Aorus Elite) este menú está en la pestaña Boot >> Secure Boot (que por ahora está deshabilitado) >> Key Management.
Si has modificado los almacenes de claves anteriormente (no es la primera vez que lo haces) es muy recomendable, para evitar errores, restaurar las claves predeterminadas antes de añadir las nuevas >> Restore Factory Keys >> Install factory defaults >> Yes.

Ahora puedes editar las claves. Seleccionas la variable que vas a modificar por este orden: Authorized Signatures >> Key Exchange Keys >> Platform Key (PK).
En cada variable puedes ver las opciones existentes. Por ejemplo, con Authorized Signatures el menú de opciones es Details / Export / Update / Append / Delete.

Para reemplazar una variable por otra eliges Update >> buscas en el dispositivo USB >> localizas y seleccionas db.auth >> esta base de datos de firmas permitidas reemplaza a la actual. Igualmente con Append si quieres añadirla a la existente en lugar de reemplazarla. Puedes utilizar Append con db.auth y kek.auth pero pk.auth sólo permite Update.
Para ver los detalles seleccionas Details >> se muestran los detalles de la variable. En el caso de Authorized Signatures, después de añadir db.auth veo las 4 firmas autorizadas: la que yo he creado (ISK Image Signing Key), las 2 de Microsoft para poder arrancar Windows con UEFI Secure Boot habilitado y la de Canonical (extraída desde el archivo shimx64.efi de Ubuntu con la herramienta shim-to-cert.tool incluida en OpenCore) para poder arrancar también Ubuntu con UEFI Secure Boot.

2. KeyTool

KeyTool se incluye en el paquete efitools de Linux, puedes encontrar la utilidad en la carpeta /usr/share/efitools/efi/KeyTool.efi. Copia este archivo a la carpeta EFI de un dispositivo USB (formateado como FAT32 y MBR) con el nombre bootx64.efi. Junto a bootx64.efi, en la carpeta EFI del dispositivo USB hay que incluir también los archivos db.auth, kek.auth y pk.auth.
Al arrancar desde este USB de arranque, se ejecuta la interfaz gráfica de la herramienta. Cuando arranca keytool vemos un menú con las opciones Save Keys / Edit Keys / Execute Binary / Exit. Hacemos clic en Edit Keys.

Seleccionamos la variable que vamos a modificar por este orden: The Allowed Signature Database (db) >> The Key Exchange Keys Database (kek) >> The Platform Key (pk).
Selecciona en primer lugar The Allowed Signature Database (db) >> Replace Keys >> dispositivo USB >> db.auth >> pulsa Enter >> vuelves a la lista de variables (sólo muestra mensaje en caso de error). Repite lo mismo para The Key Exchange Keys Database (kek) y The Platform Key (pk).

Después de introducir db.auth, kek.auth y pk.auth en el firmware podemos arrancar OpenCore y macOS con UEFI Secure Boot habilitado.

11 comentarios en «OpenCore y UEFI Secure Boot con WSL»

  1. Buenos días, Luis, antes de nada decirte que en mi blog no pongo limitaciones a la hora de nombrar foros, ya sé que entre IM y tonymacx86 no se permiten referencias directas cruzadas pero en mi caso no veo problema alguno. En el pasado he seguido guías de tonymacx86 y las tengo publicadas, pero desde que OpenCore alcanzó cierta madurez los métodos de UniBeast y otros han dejado de ser útiles para mí.
    Olarila lo conozco, soy usuario e incluso estoy probando desde hace 1 semana un DSDT específico para mi PC que me ha preparado Mald0n a quien por cierto considero tal vez el mayor experto en ACPI del mundo hackintosh, uno de los gurús, muy centrado en DSDT y SSDT. Además es moderador de InsanelyMac. Sólo le veo la pega del amor por la publicidad de las donaciones 🙂 ya no caben más anuncios en sus páginas. Pero vamos que es un sitio muy conocido y con sus EFIs prediseñadas ayuda a muchísimos novatos.
    Hablando de este DSDT que me hizo, que funciona perfectamente (mi impresión es que macOS funciona igual de bien con su DSDT o con los SSDT recomendados por Dortania), sólo hay un detalle que trato de que me o arregle, con el DSDT no hay forma de arrancar Windows desde OpenCore, da un BIOS_ACPI_ERROR porque algo del DSDT es pasado a Windows y este no arranca, en cambio con los 4 SSDT que uso sí que arranca bien, son archivos de poco código y todos tienen métodos If (_OSI("Darwin")) y el DSDT de Mald0n está pensado sólo para macOS y algún código sin ese método pasa a Windows.
    He visto tu hilo en Olarila, veo que tienes el AMD perfectamente instalado, muy bien trabajado. No veo RestrictEvents.kext, información de sistema muestra bien el modelo de CPU?
    Si deseas comentar algo, puedes hacerlo por aquí o en el email eaperez arroba me punto com (júntalo todo), como prefieras. Lo digo por ser comentarios más personales que tal vez no aportan al blog. Así tienes un contacto más en la agenda.
    Saludos, Emilio.

  2. La verdad que sí, es el primer trabajo en sh, je, je. Aunque he de decir que conozco algún otro idioma como Java, C o C++. Las modificaciones a las que me refería son de cara al usuario, por ejemplo, hacerla más amigable o visual, permitirle elegir qué archivos efi quiere firmar, a parte de los obligatorios.

    Cuando instalé Windows 11 en mi ordenador pensé, al principio, que me iba a arrepentir por sus necesidades específicas como el arranque seguro o el TPM. Indagando en la red un poquito, concretamente en un foro de hackintosh especializado en procesadores AMD (no quiero hacer spam), encontré a una persona que compartió su proyecto muy parecido al mío que, con unas pequeñas modificaciones ajuntándolo a mi hardware, funciona perfecto. No obstante, antes de descubrir dicho proyecto, tengo en otro foro, de carácter más general (empieza por Ora), mi propio proyecto que, si no recuerdo mal, se llama MacOS 11.3 & Windows 10 on AMD Ryzen. Ahora mismo estoy en la versión 12.1 de macOS.

    La principal razón por la que me decanté por los procesadores AMD fue por su mayor eficiencia en cálculos matemáticos, pues los necesitaba cuando me saqué la carrera, aunque también he tenido Intel.

    El proceso de instalar macOS en un ordenador cualquiera (AMD/Intel) es mucho más sencillo ahora que antes. Aún recuerdo parchear la AMD HD 6850M para Mavericks, utilizando la VBIOS para poder determinar el framebuffer y hacer que los conectores funcionaran. Ahora es añadir los conectores en la sección DeviceProperties, junto con la VBIOS. En definitiva, un proceso mucho más intuitivo y natural.

    Un cordial saludo y seguimos en contacto.

  3. Luis, de error nada, sólo faltaba eso. gracias a ti por tu aportación. Actualizaré el script a la versión nueva aunque es un cambio menor porque lo principal ya lo hacía bien desde la primera versión. Y si es el primer trabajo en sh, no te ha quedado nada mal, te lo aseguro.

    La mayoría de veces en que hemos necesitado usar OpenCore con UEFI Secure Boot ha sido por casos similares al tuyo, alguien usa ambos sistemas en un hackintosh y necesita arranque seguro, en tu caso por una aplicación y en mi caso porque, al salir Windows 11, interpreté que lo iba a exigir aunque después he visto que sólo exige que el PC sea capaz de arranque seguro, no que esté activado. De cualquier forma es una tarea alejada del usuario medio, no digo ya del novato o principiante. Hacerlo desde Linux y actualizar almacenes de claves del firmware, ahora que lo estudié y lo tengo más o menos claro parece fácil pero cuando me puse a ello me sonaba a chino, como se dice vulgarmente.

    Dime dónde tienes más actualizado el proyecto AMD para poder visitarlo. Yo no soy informático de formación, sólo por afición, y con las CPU Intel me siento cómodo y me da pereza probar AMD. Tienes razón en que OpenCore está consiguiendo que, con el hardware adecuado, instalar macOS en una CPU Intel está perdiendo gran parte de su dificultad.

    Un saludo y seguiremos en contacto.

  4. Buenas noches Emilio, he conseguido arreglar el script de tal manera que, si lo introducido por el usuario es «y» o «Y», en la parte que hemos mencionado, lo firma, en caso contrario borra los archivos OpenLinuxBoot.efi y ext4_x64.efi.

    Agradezco que quieras colaborar, por ello te pido que, si en GitHub cometo algún error, te sientas libre de arreglarlo.

    Respecto al PC, sí, actualmente lo utilizo, aunque tengo abandonado el proyecto en GitHub puesto que lo tengo publicado en otra página, un poco más actualizado. Si bien es cierto, hay ciertas características que no funcionan en las CPUs de AMD, como Sidecar. Me pareció una buena nueva experiencia en el mundo de hackintosh con las CPUs de AMD porque con los Intel me parecía algo trivial, gracias a los avances del bootloader OpenCore.

    No obstante, me he encontrado con una aplicación de Windows que requiere tener activada la característica de arranque seguro para poder funcionar. Indagué y encontré este estupendo tutorial y decidí hacer un script para automatizar el proceso de la creación de las claves para incorporar a los sistemas UEFI, junto con los archivos efi de una manera más simple de cara al usuario final. He de reconocer que es la primera vez que programo en sh y resultó decepcionante las primeras horas pero, al final, lo conseguí.

    Por último, decirte que he creado el repositorio en GitHub donde he subido el script corregido. De nuevo, pido disculpas por mi error inicial.

    https://github.com/Lukakeiton/sign-OC

  5. Pues muchas gracias de nuevo. Puse una nota con tu script en el artículo de mi blog justo antes de la sección Incluir los archivos en el firmware, te nombré como LUKAKEITON así que quedó bien.
    Veo que tienes algunas cosas en GitHub, puedes crear un repositorio nuevo que contenga el archivo de código sign_oc.sh con un README.md que explique brevemente lo que es y yo enlazo mi artículo con el código directamente. Y por supuesto en lo que pueda ayudar pues cuenta conmigo.
    Veo el repositorio sobre ROG-STRIX-X570-E-GAMING, buena máquina, sigues con ella? funciona bien con Big Sur? Yo siempre he tenido CPU Intel, nunca me animé a probar AMD.
    Respecto a OpenLinuxBoot.efi, no me fijé en que el archivo sólo era copiado pero no firmado al responder no, creo que es mejor como lo vas a poner ahora, que sólo sea copiado y firmado si el usuario desea usar Linux.
    Saludos, Emilio.

  6. Hola Pol, tengo Github pero actualmente la tengo en desuso. Me alegra mucho saber que encuentras utilidad al script. El nombre prefiero que sea lukakeiton, que es el alias que utilizo siempre en internet. Si no es molestia, podemos colaborar en el proyecto de GitHub para ir mejorando poco a poco el script. Te dejo mi página https://github.com/Lukakeiton

    Respecto a tu duda, me pareció interesante mantener la posibilidad de poder firmar el archivo OpenLinuxBoot al usuario por si lo necesitaba. Acabo de revisar el script y efectivamente copia el archivo OpenLinuxBoot.efi a la carpeta destino, únicamente lo firma si la respuesta es sí (y). Le doy una vuelta y te mando el script haciendo que se borre dicho archivo en caso de respuesta negativa. Gracias por la observación.

  7. Excelente, Luis, lo he probado y me gusta lo cómodo que es el proceso, simplemente arranco WSL, ejecuto el script y obtengo todo lo necesario en la carpeta Descargas. Es un paso adelante. Gracias.
    Una duda: parece firmar digitalmente los drivers de Linux (al menos los veo en la carpeta oc de destino) independientemente de la respuesta que doy a esa cuestión («Do you use OpenLinuxBoot? (Y/N)»). ¿En tu caso es diferente lo que se obtiene al responder y o n?

  8. Perfecto, ahora es un script todo en uno, elegante y práctico, en este momento no puedo pero más tarde voy a incluirte en el artículo principal, merece la pena que otros usuarios conozcan este script incluido yo mismo, claro. Muchas gracias!!!
    Luis ¿tienes GitHub o página personal? Para nombrarte como autor, ¿pongo LUKAKEITON o prefieres algún otro nombre?

  9. Sí, pienso que están trabajando en ello aunque la prioridad es baja.
    Por un lado OpenCore incorpora desde hace pocas versiones la herramienta shim-to-cert.tool para extraer la clave pública del certificado de firma OEM (y las bases de datos db y dbx, si existen) del archivo shim de grub.
    Por otro lado en el bug tracker hay un tema titulado Support UEFI SecureBoot within OpenCore del que se deduce que hay interés en crear un método más sencillo para esta tarea.

  10. Gracias por el artículo. Muy interesante pero difícil de llevar a cabo. Sabes si en OpenCore están trabajando en un método más sencillo?

Deja un comentario