search

acidanthera / bugtracker

Acidanthera Bugtracker
377 stars 42 forks source link

OpenLinuxBoot meta-issue #1776

Open mikebeaton opened 2 years ago

mikebeaton commented 2 years ago

OpenLinuxBoot.efi driver is now live: OC-native booting of Linux without chaining via GRUB.

The config.plist Drivers section layout has changed and must be updated (to allow driver arguments, see sample files).

Any queries or directly related issues may be discussed here.

The following work is still planned. The first ~should be done before 0.7.3 release~ is now fixed, the second (which is not proving needed in any distros seen so far, and is cosmetic not functional) will be done after 0.7.3 release:

TO FIX:

TO ADD:

vit9696 commented 2 years ago

Review DIFF: https://github.com/acidanthera/OpenCorePkg/compare/239c1a533d101c9e46c675a48585dbe548998582..aa1e19bebb20a5ad112fca31b111f8ad69cb8248

vit9696 commented 2 years ago

EDIT: Outstanding tasks from here moved to https://github.com/acidanthera/bugtracker/issues/1932.

cakehonolulu commented 2 years ago

Hi! I’ve been messing with OpenLinuxBoot for two days, checking the ins-n’-outs of it.

My major concern right now is:

The unability to use it on a SecureBoot-enabled environment. Deleting the original signature from ext4_x64.efi using sbattach and resigning it with my own signature (Works for the rest of OpenCore); adding it to OC/Drivers with the proper entry in the config.plist yields all bootable entries unbootable (Black screen then back to OpenCanopy).

I’ve double-checked if disabling Secure Boot and using a bone-stock OpenCore Release (Non-debug) and OcBinaryData’s untouched ext4_x64.efi works and, yes, indeed does work.

What could the problem be? I’m willing to switch over Debug OpenCore if you need logs, I need Secure Boot enabled on my machine and unfortunately I can’t with OpenCore as it is (Because Grub chainloading doesn’t work anymore).

Thanks for your time!

mikebeaton commented 2 years ago

Chainloading grub does still work, nothing has been changed about that.

Yes, please do send a debug log with the signed ext4_x64.efi. Are you saying all boot entries fail with this, or that all Linux boot entries fail. If I've understood correctly that it's just the latter, then your solution should be just to sign the individual Linux kernel images which you wish to boot /boot/vmlinuz-{version}. I believe that should just work, but equally you'll be the first person - to my knowledge - to test it.

cakehonolulu commented 2 years ago

Chainloading grub does still work, nothing has been changed about that.

Yes, please do send a debug log with the signed ext4_x64.efi. Are you saying all boot entries fail with this, or that all Linux boot entries fail. If I've understood correctly that it's just the latter, then your solution should be just to sign the individual Linux kernel images which you wish to boot /boot/vmlinuz-{version}. I believe that should just work, but equally you'll be the first person - to my knowledge - to test it.

Yes, all of them; which I find very strange.

As soon as I get home I’ll switch to OpenCore Debug and I’ll sign everything again.

The test I’ll do will consist in entering my Windows install, Ubuntu one and macOS one, maybe that’ll give some details!

vit9696 commented 2 years ago

@cakehonolulu UEFI Secure Boot is still supported with Linux, you only need to add Linux certificates to your db variable. However, I additionally created https://github.com/acidanthera/bugtracker/issues/1796 for builtin UEFI Secure Boot support in the OpenCore.

cakehonolulu commented 2 years ago

@cakehonolulu UEFI Secure Boot is still supported with Linux, you only need to add Linux certificates to your db variable. However, I additionally created #1796 for builtin UEFI Secure Boot support in the OpenCore.

Linux boots per-se on my regular Secure Boot config; no errors no nothing.

Last I checked Ubuntu chainloads GRUB using shimx64, which uses Microsoft CA keys, which I still mantain along my own ones (Wrapped both onto 1 so that I can maintain Windows too) so that shouldn’t be a problem I guess; but I can 100% be wrong so I’m open to corrections.

cakehonolulu commented 2 years ago

Chainloading grub does still work, nothing has been changed about that.

Yes, please do send a debug log with the signed ext4_x64.efi. Are you saying all boot entries fail with this, or that all Linux boot entries fail. If I've understood correctly that it's just the latter, then your solution should be just to sign the individual Linux kernel images which you wish to boot /boot/vmlinuz-{version}. I believe that should just work, but equally you'll be the first person - to my knowledge - to test it.

Just tested.

Signed all OC’s Debug components with my keys, Windows and macOS now work.

Ubuntu doesn’t work yet, complains about OCB: LoadImage failed - Security Violation.

My best guess is that something under Linux must be re-signed as per @vit9696 ’s recommendation. I’ll double check those signatures and come back with results.

EDIT: I’ve ran sbverify on vmlinuz, @vit9696 was right all along; I assumed that Canonical signed all their binaries and kernels using Microsoft’s CA key (Same as shim); turns out it doesn’t (Which now makes 100% sense to me). They use their own certs, I’ll try adding the cert into db whitelist for a quick fix and see if it works.

EDIT: So the problem was on my side, I re-signed the kernels and now OpenCore boots Ubuntu straight-out-of-the-box.

vit9696 commented 2 years ago

You are best to add Canonical keys to the db really. https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/ImageSigning. Their manual is really ugly as it does not show how to get their certificate, but here it is: https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/CanonicalMasterCA.crt

vit9696 commented 2 years ago

There actually is a good vendor database of this in https://github.com/veracrypt/VeraCrypt-DCS/tree/master/SecureBoot. And for Linux zoo it is best to check the closed issues of https://github.com/rhboot/shim-review/issues.

mikebeaton commented 2 years ago

TL/DR:

In terms of the security model of the new Boot Entry Protocol (BEP): BEP offers new boot entries to OC (a bit like making manual Entries in config.plist), but OC actually starts them, therefore security on BEP entries (i.e. including OpenLinuxBoot (OLB)) is exactly the same model as for rest of OC.

In order to allow secure boot with OLB:

Re-signing kernels with user's own Image Signing Key works, but requires re-signing the new kernel after each distro kernel update (potentially do-able, even without disabling secure boot temporarily, since distros tend to keep a couple of old kernels around and OLB will offer these as aux. boot entries after kernel update).

Preferable to re-signing is adding the distro-specific public key (the one which is used to sign that distro's kernel files) to secure boot db - but it is not that easy to actually find distro-specific signing keys. [EDIT: See new tool a couple of posts below to address this.]

mikebeaton commented 2 years ago

TL/DR:

Current sbverify fails to verify current Fedora signing key against current Fedora kernels, but the same signing key does boot the same kernels under secure boot. Something apparently borked in sbverify tool - to look into...

mikebeaton commented 2 years ago

Tool added to OC to extract vendor kernel signing cert from GRUB shim file (shimx64.efi, shimia32.efi, shim.efi, etc.): https://github.com/acidanthera/OpenCorePkg/commit/e2819b2e3863b620bd7332c216852882f42956c9

This means there's no need to re-sign and a well defined way to get hold of the certificate required for Secure Boot, at least for distros which ship with GRUB.

cakehonolulu commented 2 years ago

I’ve been messing with it a little bit more and I have to say that it’s smooth and works superbly.

The path I decided to take was to add Canonical’s key to my db keyset (In .esl format, as they can be concatenated with my own ones and written to the UEFI db section without much hassle).

I’ll link a very useful guide: https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot

The thing is that you’ll have to convert Canonical’s .pem format to .esl; it’s easy to do so don’t worry

eugene2878 commented 2 years ago

Hi. While .contentDetails and .contentFlavour features not implemented yet. How do you fix wrong icon choise by Openlinuxboot? I have few instances when Kubuntu distro shown as Ubuntu with Ubuntu icon and Kde neon using common Linux icon.

mikebeaton commented 2 years ago

Should be possible to change the icon with .VolumeIcon.icns file in root of Linux boot volume.

mikebeaton commented 2 years ago

Hi. While .contentDetails and .contentFlavour features not implemented yet. How do you fix wrong icon choise by Openlinuxboot? I have few instances when Kubuntu distro shown as Ubuntu with Ubuntu icon and Kde neon using common Linux icon.

cc @eugene2878 https://github.com/acidanthera/OpenCorePkg/commit/43137cc2775ad9a082e2b6b094c28eeba58fa1a0

HJebbour commented 2 years ago

I don't know if I should post my issue here, but when I boot from Ubuntu or Fedora from OC using OpenLinuxBoot my audio doesn't work (It shows Dummy Output and no Input for mic), When I boot from GRUB audio works properly both input and output, any particular reason why this issue happen only with audio when booting from OC?

mikebeaton commented 2 years ago

Duplicate - already answered there.