Menu
▾
▴
tboot-devel
|
From: Oliver, D. N <dar...@in...> - 2021-03-18 22:29:23
|
Hello!
I recently went over the experience of installing, configuring and running tboot, and I want to document my experience in this thread and ask some questions.
My setup consists on the following:
1. Intel NUC8i7HVK
2. Linux Kernel 5.8.15
3. tboot-1.9.11-2.fc33.x86_64
My first step was to figure out if my hardware supports a Measured Launch. For that, I guessed that txt-info would help.
The problem is txt-info needs access to /dev/mem, which is forbidden by the Kernel Lockdown functionality, which is turned on by default with my kernel version when Secure Boot is detected.
So, txt-info doesn't work unless Kernel Lockdown is disabled. A way of reproduce this is to boot with Secure Boot disabled, run txt-info successfully, enable Kernel Lockdown, and try to run txt-info again:
[root@localhost test]# mokutil --sb-state
SecureBoot disabled
[root@localhost test]# cat /sys/kernel/security/lockdown
[none] integrity confidentiality
[root@localhost test]# sudo txt-stat
Intel(r) TXT Configuration Registers:
STS: 0x00000083
....
[root@localhost test]# echo integrity > /sys/kernel/security/lockdown
[root@localhost test]# txt-stat
ERROR: cannot open /dev/mem
So, I need to run with Secure Boot disabled. The output of txt-stat is the following:
[root@localhost test]# txt-stat
Intel(r) TXT Configuration Registers:
STS: 0x00000083
senter_done: TRUE
sexit_done: TRUE
mem_config_lock: FALSE
private_open: TRUE
locality_1_open: FALSE
locality_2_open: FALSE
ESTS: 0x00
txt_reset: FALSE
E2STS: 0x0000000000000004
secrets: FALSE
ERRORCODE: 0x00000000
DIDVID: 0x00000001b0068086
vendor_id: 0x8086
device_id: 0xb006
revision_id: 0x1
FSBIF: 0xffffffffffffffff
QPIIF: 0x000000009d003000
SINIT.BASE: 0x00000000
SINIT.SIZE: 0B (0x0)
HEAP.BASE: 0x00000000
HEAP.SIZE: 0B (0x0)
DPR: 0x0000000000000000
lock: FALSE
top: 0x00000000
size: 0MB (0B)
PUBLIC.KEY:
2d 67 dd d7 5e f9 33 92 66 a5 6f 27 18 95 55 ae
77 a2 b0 de 77 42 22 e5 de 24 8d be b8 e3 3d d7
***********************************************************
TXT measured launch: TRUE
secrets flag set: FALSE
***********************************************************
unable to find TBOOT log
>From that output, I guessed that I can do a measured launch ("TXT measured launch: TRUE"). But I wanted to double check that.
According to [1], I guessed that I need SMX (Safer Mode Extensions) in my CPU to actually do a Measured Launch (although this is not mentioned in any place in tboot docs)
Unfortunately, cpuid say that my hardware does not support SMX:
[root@localhost test]# cpuid | grep SMX
SMX: safer mode extensions = false
Anyways, the tboot docs say that it will fall-through to a non-TXT boot in the case that it is not supported [2].
So, I just set it up to check what happened.
I got my 8th_9th_gen_i5_i7-SINIT_81.zip SINIT ACM module from [3], unzipped it and copy the bin file to /boot, and updated that grub configuration.
After the initial boot, I got the error message that multiboot2 and relocator could not be found. So I followed the docs on how to install them. In Fedora they are provided by the grub2-efi-x64-modules package
After reboot and selecting tboot in the grub menu, boot failed and got a recovery shell.
By inspecting the generated /run/initramfs/rdsosreport.txt, the relevant error message I can see is:
systemctl[509]: Failed to switch root: Specified switch root path '/sysroot' does not seems to be an OS tree. os-release file is missing.
By this I guess that the generated tboot generated grub configuration is broken.
After visual inspection and manual edit of the grub.cfg file, I was able to get a valid configuration (rootflags was missing)
[root@localhost fedora]# diff grub.cfg grub.cfg.bak
206c206
< module2 /vmlinuz-5.8.15-301.fc33.x86_64 root=UUID=f9f79342-5c5b-445e-ac3a-b4731f57e6e2 ro rootflags=subvol=root rhgb quiet intel_iommu=on noefi
---
> module2 /vmlinuz-5.8.15-301.fc33.x86_64 root=UUID=f9f79342-5c5b-445e-ac3a-b4731f57e6e2 ro rhgb quiet intel_iommu=on noefi
And after that, I got the following tboot log
[root@localhost fedora]# txt-stat
Intel(r) TXT Configuration Registers:
STS: 0x00000083
senter_done: TRUE
sexit_done: TRUE
mem_config_lock: FALSE
private_open: TRUE
locality_1_open: FALSE
locality_2_open: FALSE
ESTS: 0x00
txt_reset: FALSE
E2STS: 0x0000000000000004
secrets: FALSE
ERRORCODE: 0x00000000
DIDVID: 0x00000001b0068086
vendor_id: 0x8086
device_id: 0xb006
revision_id: 0x1
FSBIF: 0xffffffffffffffff
QPIIF: 0x000000009d003000
SINIT.BASE: 0x00000000
SINIT.SIZE: 0B (0x0)
HEAP.BASE: 0x00000000
HEAP.SIZE: 0B (0x0)
DPR: 0x0000000000000000
lock: FALSE
top: 0x00000000
size: 0MB (0B)
PUBLIC.KEY:
2d 67 dd d7 5e f9 33 92 66 a5 6f 27 18 95 55 ae
77 a2 b0 de 77 42 22 e5 de 24 8d be b8 e3 3d d7
***********************************************************
TXT measured launch: TRUE
secrets flag set: FALSE
***********************************************************
TBOOT log:
max_size=32706
zip_count=0
curr_pos=5308
buf:
TBOOT: *********************** TBOOT ***********************
TBOOT: 2019-11-25 16:00 +0200 1.9.11
TBOOT: *****************************************************
TBOOT: command line: logging=serial,memory
TBOOT: IA32_FEATURE_CONTROL_MSR: 00000005
TBOOT: ERR: CPU does not support SMX
TBOOT: IA32_FEATURE_CONTROL_MSR: 00000005
TBOOT: ERR: CPU does not support SMX
TBOOT: BSP is cpu 0
TBOOT: original e820 map:
TBOOT: 0000000000000000 - 0000000000058000 (1)
TBOOT: 0000000000058000 - 0000000000059000 (2)
TBOOT: 0000000000059000 - 000000000009e000 (1)
TBOOT: 000000000009e000 - 0000000000100000 (2)
TBOOT: 0000000000100000 - 0000000077a3e000 (1)
TBOOT: 0000000077a3e000 - 0000000077a3f000 (4)
TBOOT: 0000000077a3f000 - 0000000077a40000 (2)
TBOOT: 0000000077a40000 - 000000007e6d5000 (1)
TBOOT: 000000007e6d5000 - 000000007eb99000 (2)
TBOOT: 000000007eb99000 - 000000007ebf8000 (3)
TBOOT: 000000007ebf8000 - 000000007ec58000 (4)
TBOOT: 000000007ec58000 - 000000007f72c000 (2)
TBOOT: 000000007f72c000 - 000000007f7fe000 (20)
TBOOT: 000000007f7fe000 - 000000007f7ff000 (1)
TBOOT: 000000007f7ff000 - 0000000080000000 (2)
TBOOT: 00000000e0000000 - 00000000f0000000 (2)
TBOOT: 00000000fe000000 - 00000000fe011000 (2)
TBOOT: 00000000fec00000 - 00000000fec01000 (2)
TBOOT: 00000000fed00000 - 00000000fed01000 (2)
TBOOT: 00000000fee00000 - 00000000fee01000 (2)
TBOOT: 00000000ff000000 - 0000000100000000 (2)
TBOOT: 0000000100000000 - 000000027f000000 (1)
TBOOT: checking if module is an SINIT for this platform...
TBOOT: ACM info_table version mismatch (6)
TBOOT: chipset production fused: 1
TBOOT: chipset ids: vendor: 0x8086, device: 0xb006, revision: 0x1
TBOOT: processor family/model/stepping: 0x906e9
TBOOT: platform id: 0xc000000000000
TBOOT: 1 ACM chipset id entries:
TBOOT: vendor: 0x8086, device: 0xb008, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT: chipset id mismatch
TBOOT: checking if module is an SINIT for this platform...
TBOOT: ACM size mismatch: acmod_size=2ae9c02, acm_hdr->size*4=c0c0c0c0
TBOOT: no SINIT AC module found
TBOOT: TXT.SINIT.BASE: 0x0
TBOOT: TXT.SINIT.SIZE: 0x0 (0)
TBOOT: SINIT ACM not provided.
TBOOT: reserving tboot memory log (60000 - 67fff) in e820 table
TBOOT: replaced memory map:
TBOOT: 0000000000000000 - 0000000000058000 (1)
TBOOT: 0000000000058000 - 0000000000059000 (2)
TBOOT: 0000000000059000 - 0000000000060000 (1)
TBOOT: 0000000000060000 - 0000000000068000 (2)
TBOOT: 0000000000068000 - 000000000009e000 (1)
TBOOT: 000000000009e000 - 0000000000100000 (2)
TBOOT: 0000000000100000 - 0000000077a3e000 (1)
TBOOT: 0000000077a3e000 - 0000000077a3f000 (4)
TBOOT: 0000000077a3f000 - 0000000077a40000 (2)
TBOOT: 0000000077a40000 - 000000007e6d5000 (1)
TBOOT: 000000007e6d5000 - 000000007eb99000 (2)
TBOOT: 000000007eb99000 - 000000007ebf8000 (3)
TBOOT: 000000007ebf8000 - 000000007ec58000 (4)
TBOOT: 000000007ec58000 - 000000007f72c000 (2)
TBOOT: 000000007f72c000 - 000000007f7fe000 (20)
TBOOT: 000000007f7fe000 - 000000007f7ff000 (1)
TBOOT: 000000007f7ff000 - 0000000080000000 (2)
TBOOT: 00000000e0000000 - 00000000f0000000 (2)
TBOOT: 00000000fe000000 - 00000000fe011000 (2)
TBOOT: 00000000fec00000 - 00000000fec01000 (2)
TBOOT: 00000000fed00000 - 00000000fed01000 (2)
TBOOT: 00000000fee00000 - 00000000fee01000 (2)
TBOOT: 00000000ff000000 - 0000000100000000 (2)
TBOOT: 0000000100000000 - 000000027f000000 (1)
TBOOT: adjusted e820 map:
TBOOT: 0000000000000000 - 0000000000058000 (1)
TBOOT: 0000000000058000 - 0000000000059000 (2)
TBOOT: 0000000000059000 - 0000000000060000 (1)
TBOOT: 0000000000060000 - 0000000000068000 (2)
TBOOT: 0000000000068000 - 000000000009e000 (1)
TBOOT: 000000000009e000 - 0000000000100000 (2)
TBOOT: 0000000000100000 - 0000000077a3e000 (1)
TBOOT: 0000000077a3e000 - 0000000077a3f000 (4)
TBOOT: 0000000077a3f000 - 0000000077a40000 (2)
TBOOT: 0000000077a40000 - 000000007e6d5000 (1)
TBOOT: 000000007e6d5000 - 000000007eb99000 (2)
TBOOT: 000000007eb99000 - 000000007ebf8000 (3)
TBOOT: 000000007ebf8000 - 000000007ec58000 (4)
TBOOT: 000000007ec58000 - 000000007f72c000 (2)
TBOOT: 000000007f72c000 - 000000007f7fe000 (20)
TBOOT: 000000007f7fe000 - 000000007f7ff000 (1)
TBOOT: 000000007f7ff000 - 0000000080000000 (2)
TBOOT: 00000000e0000000 - 00000000f0000000 (2)
TBOOT: 00000000fe000000 - 00000000fe011000 (2)
TBOOT: 00000000fec00000 - 00000000fec01000 (2)
TBOOT: 00000000fed00000 - 00000000fed01000 (2)
TBOOT: 00000000fee00000 - 00000000fee01000 (2)
TBOOT: 00000000ff000000 - 0000000100000000 (2)
TBOOT: 0000000100000000 - 000000027f000000 (1)
TBOOT: got sinit match on module #2
TBOOT: no LCP module found
TBOOT: ELF magic number is not matched, image is not ELF format.
TBOOT: assuming kernel is Linux format
TBOOT: Initrd from 0x7bbeb000 to 0x7e6d4c02
TBOOT: Kernel (protected mode) from 0x1000000 to 0x1b243f0
TBOOT: Kernel (real mode) from 0x69c00 to 0x6d800
TBOOT: Linux cmdline from 0x72900 to 0x72d00:
TBOOT: root=UUID=f9f79342-5c5b-445e-ac3a-b4731f57e6e2 ro rootflags=subvol=roo
TBOOT: t rhgb quiet intel_iommu=on noefi
TBOOT: EFI memmap: memmap base: 0x483b0, memmap size: 0x7b0
TBOOT: EFI memmap: descr size: 0x30, descr version: 0x1
TBOOT: transfering control to kernel @0x1000000...
>From what I see on the log, I have no SMX, and my SINIT ACM is bad (I guess)
Questions
========
1. Any way to test tboot in hardware that does not support SMX/TXT? Any simulator available?
2. Do I actually need SMX to do a Measured Launch? Or is the presence of "TXT measured launch: TRUE" string the txt-stat enough to say that my hardware supports it?
3. Is the invalid tboot generated grub configuration a bug? If so, where should I submit it?
4. Am I using the correct SINIT ACM module? Is my resulting txt-stat output the expected one for my scenario?
Many thanks!
References
=========
[1] https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol2/o_b5573232dd8f1481-1975.html
[2] http://hg.code.sf.net/p/tboot/code/file/tip/README.md
[3] https://software.intel.com/content/www/us/en/develop/articles/intel-trusted-execution-technology.html
|
|
From: Lukasz H. <luk...@li...> - 2021-03-19 12:17:21
|
Hi Oliver
On Thu, 2021-03-18 at 22:29 +0000, Oliver, Dario N wrote:
> So, I need to run with Secure Boot disabled.
TBOOT will not work with Secure Boot, when Secure Boot is enabled, GRUB
has to verify signature of all components that are going to be launched.
As tboot.gz file does not support signing, it is unable to use it with
Secure Boot.
There is an experimental implementation of Secure Boot support in TBOOT,
it is not officially released, but you can look at 2.x branch if you
want to test it by yourself.
> ***********************************************************
> TXT measured launch: TRUE
> secrets flag set: FALSE
> ***********************************************************
> unable to find TBOOT log
>
> From that output, I guessed that I can do a measured launch ("TXT measured launch: TRUE"). But I wanted to double check that.
> According to [1], I guessed that I need SMX (Safer Mode Extensions) in my CPU to actually do a Measured Launch (although this is not mentioned in any place in tboot docs)
> Unfortunately, cpuid say that my hardware does not support SMX:
>
> [root@localhost test]# cpuid | grep SMX
> SMX: safer mode extensions = false
That's a misleading message, "TXT measured launch" should be false, I
guess that because TXT is not available in your platform, txt-stat reads
some garbage from TXT registers space and by mistake interprets that as
"TXT measured launch: TRUE".
If your CPU does not support SMX there is no possibility to do TXT
measured launch.
> Questions
> ========
>
> 1. Any way to test tboot in hardware that does not support SMX/TXT? Any simulator available?
It depends what do you want to test. Without TXT you can only do what
you already did - load TBOOT via multiboot2, verify that platform is not
TXT capable and fallback to standard Linux boot.
> 2. Do I actually need SMX to do a Measured Launch? Or is the presence of "TXT measured launch: TRUE" string the txt-stat enough to say that my hardware supports it?
In general, you can measure Linux during boot process without SMX,
however the idea of TBOOT is to use TXT to do a measured launch and TXT
requires SMX. No SMX -> no TXT -> TBOOT will not measure anything.
As I point earlier, this message is misleading, your hardware does not
support TXT because "TBOOT: ERR: CPU does not support SMX".
> 3. Is the invalid tboot generated grub configuration a bug? If so, where should I submit it?
Looks like a bug, I will take care of it.
> 4. Am I using the correct SINIT ACM module? Is my resulting txt-stat output the expected one for my scenario?
TBOOT: chipset ids: vendor: 0x8086, device: 0xb006, revision: 0x1
[...]
TBOOT: 1 ACM chipset id entries:
TBOOT: vendor: 0x8086, device: 0xb008, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT: chipset id mismatch
Provided SINIT does not support your platform, chipset ids do not match.
Nevertheless, it does not change anything, without SMX you can't run
SINIT.
Thanks,
Lukasz
|
|
From: Oliver, D. N <dar...@in...> - 2021-03-19 17:51:49
|
I am in for testing the 2.x branch with Secure Boot support. Run into a couple of issues while building: 1. make world fails because of missing README file (it should be README.md?) 2. generated 20_linux_tboot still say tboot version is 1.9.12 (tboot_version="1.9.12") Anyways, this Dockerfile gets it built: FROM fedora:33 RUN dnf install -y mercurial-py3 trousers-devel openssl-devel zlib-devel make gcc perl-interpreter RUN hg clone http://hg.code.sf.net/p/tboot/code -r 2.x tboot-code WORKDIR tboot-code RUN cp README.md README && make world I could not find any docs on what to do after installing 2.x as regards Secure Boot. Should I sign that with my own key and perform Secure Boot customization? Can I use the Machine Owner Keys (MOK) feature of the Linux Shim to get that verified? After rebooting with Secure Boot enabled, I got the error messages saying that multiboot2 and relocator could not be found, which is weird because I still have them installed in "/boot/efi/EFI/fedora/x86_64-efi/" |
|
From: Lukasz H. <luk...@li...> - 2021-03-22 14:09:20
|
On Fri, 2021-03-19 at 17:51 +0000, Oliver, Dario N wrote: > I could not find any docs on what to do after installing 2.x as regards Secure Boot. > Should I sign that with my own key and perform Secure Boot customization? > Can I use the Machine Owner Keys (MOK) feature of the Linux Shim to get that verified? > After rebooting with Secure Boot enabled, I got the error messages saying that multiboot2 and relocator could not be found, which is weird because I still have them installed in "/boot/efi/EFI/fedora/x86_64-efi/" If you 'make all' TBOOT, you should get tboot.mb2 file inside tboot folder. That binary can be signed with standard sbsign tool and then loaded from GRUB2 using multiboot2. Looks like Fedora still does not allow to run multiboot2 kernels when Secure Boot is enabled. You should try to build GRUB2 from the upstream and then check if you will be able to boot signed tboot.mb2 file. If you face any issues I can help you and setup QEMU environment where you will be able to check how it works.TXT in QEMU does not work, but at least we should get into point where TBOOT starts and complains that platform is incompatible. I suggest to use MOK, however custom PK or KEK should also work. Generate your own key, provision it to MOK database and sign tboot.mb2 Thanks, Lukasz |
|
From: Oliver, D. N <dar...@in...> - 2021-03-25 00:16:59
|
Hi Lukasz,
I am having some problems to get that custom grub running with Secure Boot.
I am using an Hyper-V VM with Fedora 33 to test this, after having to reinstall the OS twice in my NUC.
I guess the end result will be the same in the VM and the NUC without TXT support.
My build instructions for grub are represented in the following Dockerfile:
FROM fedora:33
RUN dnf install -y git autoconf automake gettext-devel bison \
findutils pkgconf-pkg-config python-unversioned-command \
patch git-merge-changelog gcc flex
RUN git clone https://git.savannah.gnu.org/git/grub.git
WORKDIR grub
RUN ./bootstrap && ./configure --with-platform=efi --target=x86_64 && make
Then, the process I follow to install it in my VM are:
grub-install --efi-directory=/boot/efi
/usr/local/sbin/grub-mkconfig -o /boot/grub/grub.cfg
After this, if I disable secure boot on the VM, my custom grub (in /boot/efi/EFI/grub/grubx64.efi) gets called in the boot chain.
But if I enable secure boot, the default fedora bootloader is called (/boot/efi/EFI/fedora/grubx64.efi)
To sign my custom grub, I am using the following (I know that it works for kernels, not sure for grub):
dnf install -y sbsigntools
cat > openssl.cnf << EOF
[ req ]
distinguished_name = req_distinguished_name
x509_extensions = v3
string_mask = utf8only
prompt = no
[ req_distinguished_name ]
countryName = US
stateOrProvinceName = OR
localityName = Hillsboro
0.organizationName = Organization
commonName = Secure Boot Signing
emailAddress = sec...@te...
[ v3 ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical,CA:FALSE
extendedKeyUsage = codeSigning,1.3.6.1.4.1.311.10.3.6
nsComment = "OpenSSL Generated Certificate"
EOF
openssl req -config ./openssl.cnf \
-new -x509 -newkey rsa:2048 \
-nodes -days 3650 -outform DER \
-keyout MOK.key \
-out MOK.der
openssl x509 -in MOK.der -inform DER -outform PEM -out MOK.pem
sbsign --key MOK.key --cert MOK.pem \
--output ./grubx64.efi /boot/efi/EFI/grub/grubx64.efi
cp ./grubx64.efi /boot/efi/EFI/grub/grubx64.efi
mokutil --import MOK.der
After the reboot, I do Mok Management to import the key.
But the system keeps booting with the /boot/efi/EFI/grub/grubx64.efi Instead of my custom one.
Just to see what happens, I replaced the fedora bootloader with my custom one, and I got the following error:
error: verification requested but nobody cares: (hd0,gpt2)/grub/x86_64-efi/normal.mod
Entering rescue mode
grub rescue>
Any hints on what is happening?
|
|
From: Lukasz H. <luk...@li...> - 2021-03-26 14:46:07
|
On Thu, 2021-03-25 at 00:16 +0000, Oliver, Dario N wrote: > Hi Lukasz, > > I am having some problems to get that custom grub running with Secure Boot. > I am using an Hyper-V VM with Fedora 33 to test this, after having to reinstall the OS twice in my NUC. > I guess the end result will be the same in the VM and the NUC without TXT support. > > My build instructions for grub are represented in the following Dockerfile: > > FROM fedora:33 > RUN dnf install -y git autoconf automake gettext-devel bison \ > findutils pkgconf-pkg-config python-unversioned-command \ > patch git-merge-changelog gcc flex > RUN git clone https://git.savannah.gnu.org/git/grub.git > WORKDIR grub > RUN ./bootstrap && ./configure --with-platform=efi --target=x86_64 && make > > Then, the process I follow to install it in my VM are: > > grub-install --efi-directory=/boot/efi > /usr/local/sbin/grub-mkconfig -o /boot/grub/grub.cfg > > After this, if I disable secure boot on the VM, my custom grub (in /boot/efi/EFI/grub/grubx64.efi) gets called in the boot chain. > But if I enable secure boot, the default fedora bootloader is called (/boot/efi/EFI/fedora/grubx64.efi) > To sign my custom grub, I am using the following (I know that it works for kernels, not sure for grub): > > dnf install -y sbsigntools > cat > openssl.cnf << EOF > [ req ] > distinguished_name = req_distinguished_name > x509_extensions = v3 > string_mask = utf8only > prompt = no > [ req_distinguished_name ] > countryName = US > stateOrProvinceName = OR > localityName = Hillsboro > 0.organizationName = Organization > commonName = Secure Boot Signing > emailAddress = sec...@te... > [ v3 ] > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always,issuer > basicConstraints = critical,CA:FALSE > extendedKeyUsage = codeSigning,1.3.6.1.4.1.311.10.3.6 > nsComment = "OpenSSL Generated Certificate" > EOF > openssl req -config ./openssl.cnf \ > -new -x509 -newkey rsa:2048 \ > -nodes -days 3650 -outform DER \ > -keyout MOK.key \ > -out MOK.der > openssl x509 -in MOK.der -inform DER -outform PEM -out MOK.pem > sbsign --key MOK.key --cert MOK.pem \ > --output ./grubx64.efi /boot/efi/EFI/grub/grubx64.efi > cp ./grubx64.efi /boot/efi/EFI/grub/grubx64.efi > mokutil --import MOK.der > > After the reboot, I do Mok Management to import the key. > But the system keeps booting with the /boot/efi/EFI/grub/grubx64.efi Instead of my custom one. > > Just to see what happens, I replaced the fedora bootloader with my custom one, and I got the following error: > > error: verification requested but nobody cares: (hd0,gpt2)/grub/x86_64-efi/normal.mod > Entering rescue mode > grub rescue> > > Any hints on what is happening? Looks like you did everything correct, I am not quite sure how grub- install works, if it copies GRUB modules as standalone files you may have to sign them too. Please try to install GRUB using grub-mkimage command. That allows to include all required modules in GRUB binary, here is an example usage: ./grub-mkimage -d grub-core -O x86_64-efi -o grubx64.efi -p "/EFI/BOOT" echo all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gfxmenu gfxterm gzio halt hfsplus iso9660 jpeg loadenv lvm mdraid09 mdraid1x minicmd normal part_apple part_msdos part_gpt password_pbkdf2 png reboot search search_fs_uuid search_fs_file search_label sleep syslinuxcfg test tftp regexp video xfs relocator multiboot2 linux efinet tftp serial shim_lock multiboot As a result you will get grubx64.efi file that you can sign and copy to /boot partition replacing Fedora's GRUB. I have prepared for you demo with GRUB and TBOOT that should work under Secure Boot enabled systems [1]. You can copy all files to any USB stick and try boot your NUC from it. Of course you will have to add key to MOK database. You can use for that mmx64.efi tool, key that was used to sign binaries from the demo is also included. [1] https://cloud.hawrylko.pl/s/gVD4pFQehDaNmbp Lukasz |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X