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

Add UEFI/SecureBoot docs from Ubuntu wiki #2088

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rkratky
Copy link
Collaborator

@rkratky rkratky commented Sep 19, 2024

This adds content related to UEFI Secure Boot from the Ubuntu Wiki -- as a part of the effort to migrate docs from the wiki.

Notes:

  • The new articles are marked as WIP and not official docs.
  • While I have updated the content, added semantic mark-up, and reformatted it, more work is needed, including clean ups and removals of obsolete info; there are also sections that are marked as needing fixes.
  • The .wokeignore file has been moved to the root of the repo temporarily because of an upstream bug: Nested .wokeignore doesn't work in a git repo. get-woke/woke#212

module.ko


Using :command:`signfootl.exe` from Microsoft
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

signtool.exe? typo?

There are two options:

- Using Ubuntu directly with :command:`sbsign` and :command:`kmodsign`.
- Using the "real" method used by Microsoft to sign binaries with a Windows-only application.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth mentioning that both methods are just as real.

Microsoft signing is so that off-the-shelf Windows machines will trust your binary, otherwise you have to enroll your public key in the firmware.

Also worth noting that Microsoft signing is only available and should only be used for production code that is expected to be used by regular users on off the shelf hardware.


.. code:: none

uvt new --loader=OVMF.fd --with-ovmf-uefi xenial amd64 sb
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xenial is absolutely ancient


.. code:: none

virt-install --connect=qemu:///system --name=sb-xenial-amd64 --arch=x86_64 --ram=2048 \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also maybe we should be promoting our own product, LXD, instead of libvirt?


.. _efi-shell:

EFI shell
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EFI shell should be removed from SB article as EFI shell is forbidden from SB signing, and cannot be included in SB firmware images anymore.

Bootloader signed with Canonical key
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This emulates a configuration that supports machines with Canonical's key in KEK and DB (user key still in PK and KEK). The key database is configured with (user key in PK and KEK has the same GUID, Canonical key in KEK and db has the same GUID):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Canonical's key should be only used via shim, and not via KEK and DB currently, suggesting this is insecure.

@kukrimate
Copy link
Member

@rkratky a large part of this content is incredibly out of date, and some parts of it suggest insecure practices, I am honestly not sure if we should be displaying this in this state anywhere.

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

Successfully merging this pull request may close these issues.

2 participants