Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] GRUB 2.04 for PBA? #301

Open
tolga9009 opened this issue Sep 28, 2019 · 26 comments
Open

[Feature Request] GRUB 2.04 for PBA? #301

tolga9009 opened this issue Sep 28, 2019 · 26 comments

Comments

@tolga9009
Copy link

tolga9009 commented Sep 28, 2019

Hi,

in GRUB 2.04 changelog, the following caught my attention:

+* Native UEFI secure boot support.
+* UEFI TPM driver.

If SYSLINUX in PBA would be replaced by GRUB 2.04, would UEFI Secure Boot be a possibility? Also, it looks like there is a TPM driver now. Maybe PR #86 could benefit from this.

Any thoughts?

Source: https://git.savannah.gnu.org/cgit/grub.git/commit/?h=grub-2.04&id=2a2e10c1b39672de3d5da037a50d5c371f49b40d

@oom-is
Copy link

oom-is commented Sep 29, 2019

I'm currently working through the process of updating the buildroot part of buildpbaroot to use a more recent buildroot target/version (currently 2017.05.1, I'm trying as a first step to get to 2018.08.4). My first need is to try to fix or workaround an issue specific to Dell Optiplex XE2 (loses USB after booting the current 4.11 kernel in linuxpba-UEFI64 ) so I'm trying to get to a newer 4.14 LTS or 4.19 LTS Linux kernel.

Once that's done, though, one of my other "next needs" is Secure Boot support, and I agree that GRUB 2.x is probably a better way to get there than current syslinux 6.0.3 from 2014. (Supporting data at this page https://www.rodsbooks.com/efi-bootloaders/syslinux.html - basically even if a syslinux binary gets signed to be bootable by Secure Boot it won't correctly pass things along to the kernel.)

The bad news is that right now DTA/r0m30 don't seem to be actively maintaining the code so feel free to jump in and start trying to test/integrate new features...

@oom-is
Copy link

oom-is commented Sep 30, 2019

I am continuing to work through the updates to buildroot - looks like I'm close on that front.

In the meantime, see also issue 259 and issue 181 for more past discussion and ways forward to SecureBoot and/or GRUB 2.x.

@tolga9009
Copy link
Author

Thanks for input!

The bad news is that right now DTA/r0m30 don't seem to be actively maintaining the code

Yepp, already saw that. But it looks like the issue tracker here is still beeing used as some sort of communication platform. @ckamm and @ladar seem to have quite advanced forks.

In the meantime, see also issue 259 and issue 181 for more past discussion and ways forward to SecureBoot and/or GRUB 2.x.

I wasn't aware of them, thanks for the links!

@ghost
Copy link

ghost commented Oct 3, 2019

I just created an issue regarding the @ckamm fork and others. They are mostly undocumented, the initialization process is not properly detailed, and there are other potential issues. I would suggest not using or basing your work on them until that is resolved. They lack both wikis and issue trackers, and this is the wrong place for people to come reporting problems with those forks.

@ghost
Copy link

ghost commented Oct 3, 2019

@ladar's fork actually ameliorates this, so I would suggest using that if he has documented the changes applied.

@oom-is
Copy link

oom-is commented Oct 29, 2019

Two updates:

  1. Buildroot updates were in my Pull Request LTS update for Buildroot and Linux Kernel #306 if those are of interest.
  2. A UEFI-bootable ISO image with GRUB 2.04 as the primary bootloader is now available. My Pull Request ISO file builder for Rescue64 (UEFI) + GRUB #309 is the files needed to roll your own, or the DTA 1.15.1 Rescue64 repackaged as a UEFI-bootable ISO with GRUB 2.04 is available directly here for testing/validation:
    https://github.com/oom-is/sedutil/releases/download/1.15.1/sedutil-1.15.1-Rescue64UEFIgrub.iso

Since I needed a UEFI64 Rescue ISO anyway, I decided to use the ISO as a proof-of-concept for UEFI bootable grub-2.04 that might also support Secure Boot without additional signing or certs for the average user. However, I've not been able (yet) to fully test the Secure Boot support.

@OliverO2
Copy link

Secure Boot Available Now

If you are on a supported Linux distribution and you have installed Grub 2 with UEFI, you're probably just four easy steps away from a fully functional PBA supporting secure boot via Grub 2 (and more):

  1. Downloads required

  2. To prepare a PBA with secure boot enabled, put a line like this (adjusting the path as necessary) into etc/rear/local.conf:

    • SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi"
  3. Build the PBA:

    • sudo usr/sbin/rear -v mkopalpba
  4. Upload the PBA to all installed Opal 2 drives (but test it via a USB stick first):

    • sudo usr/sbin/rear opaladmin uploadPBA

You should be good to go!

If you happen to be on Ubuntu and if you'd use my latest pull request (to be merged shortly), you'd also get a nice graphical user interface for disk unlocking.

Here is a User Guide for the TCG Opal 2 support in ReaR. Ah, and of course you'll get a fully featured disaster recovery system as well, since this is what ReaR is about.

This was referenced Nov 19, 2019
@MrPumo
Copy link

MrPumo commented Nov 6, 2020

Hi,
I've created PBA as you suggested and it boot fine. Then I create the rescue ISO and while testing it by boot from... boot hang at grub 2.04 prompt.
Any suggestion?

@OliverO2
Copy link

OliverO2 commented Nov 6, 2020

@MrPumo
How did you create the PBA? You probably should not use the PBA from sedutil anymore as this project seems to have been abandoned. You could always try the rear PBA as described here, which is current, easy to build and has good community support.

@MrPumo
Copy link

MrPumo commented Nov 6, 2020

Ok. Solved.. I wrongly pushed ISO to usb instead of RAW.

Following your linked instruction it means is no more need to include in local.conf
SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi"
to have a secureboot compliant PBA, right?

@OliverO2
Copy link

OliverO2 commented Nov 6, 2020

If I remember correctly, you still need SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi" for secure boot. Maybe I should extend the Guide section in ReaR to emphasize that?

@MrPumo
Copy link

MrPumo commented Nov 6, 2020

well... I've not such entry and rescue properly generate a secureboot signed PBA..
Then please add also suggestion on how to install OS:

  • deactivate LOCK , install OS & reactivate LOCK
    or
  • boot to PBA, unlock disk, then boot removable media for OS installation

@OliverO2
Copy link

OliverO2 commented Nov 6, 2020

Will look at this, too. Thanks for the hint. Good to hear that it finally works for you. Enjoy!

@MrPumo
Copy link

MrPumo commented Nov 6, 2020

Hi, I'm sorry.. I was wrong. As you told you have to add etc/rear/local.conf also
SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi"
to have a properly SECUREBOOT signed PBA.

@OliverO2
Copy link

OliverO2 commented Nov 6, 2020

OK, thanks for the feedback!

@OliverO2
Copy link

OliverO2 commented Nov 6, 2020

Continued here: rear/rear#2511

jsmeix added a commit to rear/rear that referenced this issue Nov 9, 2020
Improved TCG Opal 2 documentation doc/user-guide/13-tcg-opal-support.adoc
cf. #2511
Better explained OS installation according to the suggestion in
Drive-Trust-Alliance/sedutil#301 (comment)
Additionally some information from an article on Ask Ubuntu are included
https://askubuntu.com/a/1271171/1120528
@ChubbyAnt
Copy link

Continuing this concept, was anyone able to create a non-rear bootloader with Grub to load sedutil (with secure boot enabled).

@OliverO2
Copy link

This is ReaR. Probably not the right place to ask for non-ReaR stuff.

@ChubbyAnt
Copy link

@OliverO2 this is the sedutil issues section (not rear).

@OliverO2
Copy link

@ChubbyAnt Ah, sorry, my fault. As far as I am aware, ReaR is currently the only solution available for unlocking SEDs in conjunction with Secure Boot and will probably remain so for some time. This is probably due to the fact that you need

  • a Linux distribution with Secure Boot support
  • small enough to meet PBA size requirements.

Ready-made low-footprint Linux distributions such as TinyCore or Alpine lack Secure Boot support. Full-blown distributions need to be stripped down properly, which is what ReaR does.

@ChubbyAnt
Copy link

Reading the thread above, it looks like people were working on either using Grub or rear as a bootloader template to then directly load sedutil. Curious if there was any success on those projects.

@OliverO2
Copy link

Hmm, I'm the one who created the ReaR PBA stuff. ReaR is a disaster recovery tool, which creates a bootable medium from a stripped-down version of your normal Linux distribution.

You cannot directly execute sedutil from Grub. sedutil needs a proper operating system to run on, with disk device support, console output support, keyboard support, etc.

@ChubbyAnt
Copy link

@OliverO2 in the rear PBA aren't you just masking commands to sedutil-cli to use sedutil to unlock the SED? Can't we just strip out all of the rear stuff and let sedutil-cli stand on its own (unmasked) using the rear bootloader (to take advantage of the rear secure boot capability)?

@OliverO2
Copy link

OliverO2 commented Jul 1, 2021

That's a gross misconception. There is no "ReaR bootloader". For Secure Boot, Grub 2 is used, which then boots up a Linux kernel, which acts as a platform to run sedutil-cli. There is much more to it than just wrapping secutil-cli calls. Beyond that you need to

  • package an operating system with a small footprint and
  • create a bootable disk partition with a properly signed EFI bootloader.

@darshans2021
Copy link

i cant able to copy PBA image in my Linux system (Ubuntu 18.0). i have already given all the permission to it but no success. Is there any dependency file for PBA image

@r0m30
Copy link
Contributor

r0m30 commented Sep 24, 2021

Have you tried using Sudo? Sometimes I've run into issues as well and Sudo has fixed them. I think it's probably related to the partition being an ESP. 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants