public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "Alexander Graf" <graf@amazon.com>,
	"Ard Biesheuvel" <ardb@google.com>,
	devel@edk2.groups.io, "L�szl� �rsek" <lersek@redhat.com>,
	"Oliver Steffen" <osteffen@redhat.com>,
	"Herrenschmidt, Benjamin" <benh@amazon.com>,
	"Lennart Poettering" <mzxreary@0pointer.de>,
	"Peter Jones" <pjones@redhat.com>,
	"Matthew Garrett" <mjg59@srcf.ucam.org>
Subject: Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled
Date: Mon, 4 Dec 2023 23:24:29 +0100	[thread overview]
Message-ID: <jhin5htzdkbvfgmr5kedf2yinst3kglcrwfr2njpigavxpfihn@qneqwz2dj3sl> (raw)
In-Reply-To: <CAMj1kXEwDjfyM=YDWZh5GAx9k6y89it45WB4NREmozY_SjouOw@mail.gmail.com>

  Hi,

> > I'm with you on that.  Unfortunately the boot loader team is not.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2108083
> >
> > tl;dr: You can't boot Fedora in secure boot mode without microsoft keys
> > today.  grub.efi refuses to work without shim.efi, and shim.efi exists
> > only in a microsoft-signed version (which differed from rhel were a
> > second, redhat-signed shim binary exists).
> >
> > Oh, and the above applies to x86 only.  On arm fedora shim.efi is not
> > signed and grub.efi is signed with the (public) redhat test keys.
> 
> So what is holding Fedora back from providing a fixed shim binary if
> it doesn't need to be signed by Microsoft?

I'd love to have an serious answer for that question, but I havn't.
Usually I get either no answer, or something along the lines of
"-ENOTIME because of $otherwork".

Right now waiting for v6.7-final before sending a new shim.efi to
microsoft for signing and the desire to keep all archs in sync also
plays a role (I guess).

Technically there is no good reason, fedora even has a separate
shim-unsigned-$arch.rpm which could be up-to-date all the time on all
architectures, independent from the microsoft signing process.  But that
is right now at v15.6, which is not even the latest (v15.7) release.
And 15.7 is more than one year old already ...

> To be honest (and I know I am preaching to the choir here), the more i
> learn about this, the less I am inclined to make *any* accommodations
> whatsoever, given that the boot loader team obviously does not give a
> shit about their crappy boot chain.

Can understand that sentiment.  Problem is this hits the wrong people,
and the fallout goes beyond rhel + fedora because the rh team also
maintains upstream shim.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112072): https://edk2.groups.io/g/devel/message/112072
Mute This Topic: https://groups.io/mt/102967690/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-12-05  9:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04  9:52 [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled Ard Biesheuvel
2023-12-04  9:59 ` Ard Biesheuvel
2023-12-04 10:45 ` Alexander Graf via groups.io
2023-12-04 10:55   ` Ard Biesheuvel
2023-12-04 12:20   ` Gerd Hoffmann
2023-12-04 12:38     ` Alexander Graf via groups.io
2023-12-04 12:58       ` Ard Biesheuvel
2023-12-05  9:56         ` Marcin Juszkiewicz
2023-12-07  8:04           ` Ard Biesheuvel
2023-12-04 14:52       ` Gerd Hoffmann
2023-12-04 16:09         ` Ard Biesheuvel
2023-12-04 22:24           ` Gerd Hoffmann [this message]
2023-12-05 10:44         ` Alexander Graf via groups.io
2023-12-05 12:56           ` Gerd Hoffmann
2023-12-04 10:53 ` Gerd Hoffmann
2023-12-04 10:57   ` Ard Biesheuvel
2023-12-04 11:40     ` Gerd Hoffmann
2023-12-06 12:51       ` Gerd Hoffmann
2023-12-06 13:23         ` Ard Biesheuvel
2023-12-06 15:27           ` Gerd Hoffmann
2023-12-06 20:00             ` Taylor Beebe
2023-12-06 18:37           ` Oliver Smith-Denny
2023-12-07  7:59             ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jhin5htzdkbvfgmr5kedf2yinst3kglcrwfr2njpigavxpfihn@qneqwz2dj3sl \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox