Spec URL: https://in.waw.pl/~zbyszek/fedora/systemd-boot.spec SRPM URL: https://in.waw.pl/~zbyszek/fedora/systemd-boot-251~rc1-1.fc37.src.rpm Fedora Account System Username: zbyszek Description: systemd-boot (short: sd-boot) is a simple UEFI boot manager. It provides a graphical menu to select the entry to boot and an editor for the kernel command line. systemd-boot supports systems with UEFI firmware only. This package contains the signed version that that works with Secure Boot.
This package currently uses systemd-udev as the source. Once we split out systemd-boot-unsigned in the main systemd rpm and that is available, it can switch to that. This only difference that this will make is that the unsigned files don't need to be installed on user systems. https://src.fedoraproject.org/rpms/systemd/pull-request/78 is the corresponding PR to split out systemd-boot-unsigned from the systemd package.
Questions/notes: 1) should this buildrequire the exact same version of %{source_rpm_name}? 2) "# self-obsoletes to install both packages after the split" this is not "self-obsoletes"
Other than that, the spec looks reasonable. Not sure how to verify the bootctl scriptlet works thou.
(In reply to Miro Hrončok from comment #2) > Questions/notes: > > 1) should this buildrequire the exact same version of %{source_rpm_name}? I wanted to avoid that because it'd mean that we'd need to manually copy the version. The motivation for splitting this package out is that it'll be built (presumably much) less often than the systemd package. So the release numbers will get out of sync. And in fact systemd-boot does not need to match the systemd version: we generally want to update it whenever there's a new version, but it could be before or after the systemd package. (systemd-boot generally must support booting newer and older systems in multiboot scenarios, and non-linux systems, etc.) > 2) "# self-obsoletes to install both packages after the split" this is not > "self-obsoletes" Adjusted in place.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > (In reply to Miro Hrončok from comment #2) > > Questions/notes: > > > > 1) should this buildrequire the exact same version of %{source_rpm_name}? > > I wanted to avoid that because it'd mean that we'd need to manually copy the > version. > The motivation for splitting this package out is that it'll be built > (presumably much) less > often than the systemd package. So the release numbers will get out of sync. > And in fact systemd-boot does not need to match the systemd version: we > generally want > to update it whenever there's a new version, but it could be before or after > the systemd > package. (systemd-boot generally must support booting newer and older > systems in multiboot > scenarios, and non-linux systems, etc.) It will be quite confusing when this package version will be 251~rc1 but the stuff it signed will be 252~rc3. That's why. Release numbers can get out of sync, I was talking about the version. E.g.: BuildRequires: %{source_rpm_name} = %{version} ----------- Related suggestion -- what if you added: Provides: bundled(%{source_rpm_name}) = %(rpm -q --qf '%%{VERSION}-%%{RELEASE}') That way, the version-release will be repoqueriable. The current way, the version is only in description, which is harder to get.
OK, that makes sense. Adjusted in place: $ rpm -qpP /var/lib/mock/fedora-rawhide-x86_64/result/systemd-boot-251\~rc1-2.fc37.x86_64.rpm bundled(systemd-udev) = 251~rc1-3.fc37 systemd-boot = 251~rc1-2.fc37 systemd-boot(x86-64) = 251~rc1-2.fc37 $ rpm -qpi /var/lib/mock/fedora-rawhide-x86_64/result/systemd-boot-251\~rc1-2.fc37.x86_64.rpm ... Built from systemd-udev-251~rc1-3.fc37.x86_64. > Not sure how to verify the bootctl scriptlet works thou. All the scriptlet does is call 'bootctl update'. So you can just run that as root on a machine with sd-boot installed, and it should give the same result: $ sudo bootctl update Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/efi/EFI/systemd/systemd-bootx64.efi". Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/efi/EFI/BOOT/BOOTX64.EFI". It might turn out that the scriplets are too verbose. This can be easily adjusted later, and it's easier to start with more logs to catch any mistakes… And of course I have no idea if the signed package will actually pass SB checks. I think it should, but this will need to wait for the official build. (And even if it does *not* pass, we shouldn't be any worse of than now.)
Taking this review.
There's a couple of things you probably want to do here: * The systemd-boot-unsigned and systemd-boot packages should have their efi architectures as suffixes, similar to shim and grub * Since this package provides the signed versions, please add systemd-boot-signed-%efi_arch Provides (shim does this too)
> %postun > if [ $1 -ge 1 ] && bootctl is-installed &>/dev/null; then > echo "Updating systemd-boot…" > bootctl update || : > fi Since you're an upstream developer, I suggest you see if you can add -q/--quiet to bootctl like systemctl has, so that /dev/null things don't need to be done here.
(In reply to Neal Gompa from comment #9) > > %postun > > if [ $1 -ge 1 ] && bootctl is-installed &>/dev/null; then > > echo "Updating systemd-boot…" > > bootctl update || : > > fi > > Since you're an upstream developer, I suggest you see if you can add > -q/--quiet to bootctl like systemctl has, so that /dev/null things don't > need to be done here. Obviously not blocking on this, though :)
(In reply to Neal Gompa from comment #8) > There's a couple of things you probably want to do here: > > * The systemd-boot-unsigned and systemd-boot packages should have their efi > architectures as suffixes, similar to shim and grub Hmm, but why? I don't see any guideline that'd require this, and it makes things more complicated. > * Since this package provides the signed versions, please add > systemd-boot-signed-%efi_arch Provides (shim does this too) What about 'Provides:systemd-boot-signed(%{efi_arch)) = %version-%release' ?
> The motivation for splitting this package out is that it'll be built > (presumably much) less > often than the systemd package. So the release numbers will get out of sync. > And in fact systemd-boot does not need to match the systemd version: we > generally want > to update it whenever there's a new version, but it could be before or after > the systemd This is why it should be a separate project/source upstream to systemd, the bootloaders are statically linked PE-COFF/UEFI binaries so won't use libraries etc from systemd, it will by definition have different CVEs and different code. With a different repo it can release when it has new features/fixes and be independent bumps which is especially useful for dealing with CVEs.
> This is why it should be a separate project/source upstream to systemd Let's try to keep the scope of this ticket to the review. The separate code thingy has been discussed (and refuted) on the mailing list, see e.g. https://lists.freedesktop.org/archives/systemd-devel/2022-April/047828.html .
(In reply to Zbigniew Jędrzejewski-Szmek from comment #13) > > This is why it should be a separate project/source upstream to systemd > > Let's try to keep the scope of this ticket to the review. > The separate code thingy has been discussed (and refuted) on the mailing > list, > see e.g. > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047828.html . There's nothing in that post that refuted or even addresses any of my points above. If three's a CVE that's against systemd it covers all of systemd and hence the CVE still applies to sd-boot even if the code is unaffected. None of that was addressed in that post.
> What about 'Provides:systemd-boot-signed(%{efi_arch)) = %version-%release' ? Added: +Provides: systemd-boot-signed-%{efi_arch} = %version-%release and in the systemd pr: +Provides: systemd-boot-unsigned-%{efi_arch} = %version-%release I guess that using -%{efi_arch} has the advantage that (%{efi_arch}) could be mistaken and/or interfere with (%{_isa}). -- > There's nothing in that post that refuted or even addresses any of my points above. You wrote "it will by definition have different CVEs and different code", and that post and the rest of the thread discusses how systemd-boot and bootctl actually share code. Even more importantly, they share implementation logic (even if sometimes we need to have two separate implementations), so the same bugs could and in practice do affect both. The rest of your analysis is based on this flawed assumption. > If three's a CVE that's against systemd it covers all of systemd and hence the CVE still applies to sd-boot even if the code is unaffected I don't know what you're trying to say. CVEs generally apply to some specific part of the code, which means that (for a project like systemd that builds multiple binaries), it applies to one or more binaries. When analyzing a CVE, figuring out *where* it applies is generally one of the first steps. So we will know if the boot loader binaries can be affected, and whether to update them or not. Whether the packages are separate or not would only matter if we were mechanically creating an update for every CVE without any scope analysis. > With a different repo it can release when it has new features/fixes True. > and be independent bumps which is especially useful for dealing with CVEs. Actually we retain the ability to do independent bumps even with the split as it is implemented now.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #11) > (In reply to Neal Gompa from comment #8) > > There's a couple of things you probably want to do here: > > > > * The systemd-boot-unsigned and systemd-boot packages should have their efi > > architectures as suffixes, similar to shim and grub > > Hmm, but why? I don't see any guideline that'd require this, and it makes > things more complicated. > There's no guidelines for EFI stuff in Fedora because nobody expected anyone to do more than shim+grub. The only reason I know (outside of the RH bootloader people) how all this works is because I spent two years doing research on the whole thing. This split makes it possible for multiple EFI variants to be installed at once (e.g. ia32 + x64, etc.). > > * Since this package provides the signed versions, please add > > systemd-boot-signed-%efi_arch Provides (shim does this too) > > What about 'Provides:systemd-boot-signed(%{efi_arch)) = %version-%release' ? Sure, I'm fine with that. It's inconsistent with the others, but meh...
(In reply to Zbigniew Jędrzejewski-Szmek from comment #15) > > What about 'Provides:systemd-boot-signed(%{efi_arch)) = %version-%release' ? > > Added: > +Provides: systemd-boot-signed-%{efi_arch} = %version-%release > and in the systemd pr: > +Provides: systemd-boot-unsigned-%{efi_arch} = %version-%release > > I guess that using -%{efi_arch} has the advantage that (%{efi_arch}) could > be mistaken > and/or interfere with (%{_isa}). > Yes, thanks for doing that! :)
(In reply to Peter Robinson from comment #14) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #13) > > > This is why it should be a separate project/source upstream to systemd > > > > Let's try to keep the scope of this ticket to the review. > > The separate code thingy has been discussed (and refuted) on the mailing > > list, > > see e.g. > > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047828.html . > > There's nothing in that post that refuted or even addresses any of my points > above. If three's a CVE that's against systemd it covers all of systemd and > hence the CVE still applies to sd-boot even if the code is unaffected. None > of that was addressed in that post. Note that even if we did get it split, I'm not sure I'd like setting this up the way GRUB is set up, where the signing happens as part of building the package from source. Having packages completely locked down from the community sucks balls, and this approach is nice in that the only part that's actually locked down is the part that *signs* the binary. It also makes it *really* easy for third parties to do their own signing by taking the signing spec and pointing it to their own certificates. Once this package is reviewed and accepted, I intend to finally write the guidelines I've been stalling on for how to do EFI stuff in Fedora.
> Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/efi/EFI/BOOT/BOOTX64.EFI". What's the goal of doing this with a bootloader that's signed with distro keys? How is the user expected to use this?
Hmm, what part are you asking about: boot loader installation, using UEFI, or Secure Boot, or the signature chain, or using the sd-boot loader, or some details of the process?
He's saying it should not be overwriting the shim EFI binary, and I agree, that's Bad(tm).
(In reply to Neal Gompa from comment #21) > He's saying it should not be overwriting the shim EFI binary, and I agree, that's Bad(tm). The example I showed is for the unsigned binary that replaces shim. Once the binary has been signed, we'll have to install it under a different path where shim can pick it up. From what we looked at, we might have to call ourselves either 'grubx64.efi' or 'fallbackx64.efi', because that's what shim looks for. If shim gets support for looking for a more generic name later, we could switch to that.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #22) > (In reply to Neal Gompa from comment #21) > > He's saying it should not be overwriting the shim EFI binary, and I agree, that's Bad(tm). > > The example I showed is for the unsigned binary that replaces shim. > Once the binary has been signed, we'll have to install it under a different > path where > shim can pick it up. From what we looked at, we might have to call ourselves > either 'grubx64.efi' > or 'fallbackx64.efi', because that's what shim looks for. If shim gets > support for looking for > a more generic name later, we could switch to that. Is there a BZ filed about supporting a generic name for second-stage EFI boot manager binaries? I'd like to track that too...
> Is there a BZ filed about supporting a generic name for second-stage EFI boot manager binaries? I'd like to track that too... AFAIK, no. I think that installing as 'grubx64.efi' is something that we'll have to do anyway, to support existing systems. So this isn't something that was considered high priority. We'd need to check if this was requested before, and if not file a new issue.
https://github.com/systemd/systemd/pull/23273 implements 'bootctl update --quiet --graceful' that doesn't say anything if we're on non-EFI or sd-boot is not installed. > Is there a BZ filed about supporting a generic name for second-stage EFI boot manager binaries? I'd like to track that too... https://github.com/rhboot/shim/issues/472
I tried to run fedora-review on this, but it fails to build with the following error in the root log: DEBUG util.py:443: No matching package to install: 'systemd-udev = 251~rc1' Can you bump this to ~rc2 so I can try again?
Spec URL: https://in.waw.pl/~zbyszek/fedora/systemd-boot.spec SRPM URL: https://in.waw.pl/~zbyszek/fedora/systemd-boot-251~rc2-1.fc37.src.rpm
fedora-review doesn't seem to like missing spec sections: 05-11 15:47 root DEBUG Running check: CheckSourceVerification 05-11 15:47 root DEBUG Exception down the road... Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/FedoraReview/review_helper.py", line 236, in run self._do_run(outfile) File "/usr/lib/python3.10/site-packages/FedoraReview/review_helper.py", line 226, in _do_run self._do_report(outfile) File "/usr/lib/python3.10/site-packages/FedoraReview/review_helper.py", line 99, in _do_report self._run_checks(self.bug.spec_file, self.bug.srpm_file, outfile) File "/usr/lib/python3.10/site-packages/FedoraReview/review_helper.py", line 117, in _run_checks self.checks.run_checks(output=output, writedown=not Settings.no_report) File "/usr/lib/python3.10/site-packages/FedoraReview/checks.py", line 382, in run_checks run_check(name) File "/usr/lib/python3.10/site-packages/FedoraReview/checks.py", line 357, in run_check check.run() File "/usr/lib/python3.10/site-packages/FedoraReview/plugins/generic_should.py", line 584, in run for line in self.spec.get_section("prep"): TypeError: 'NoneType' object is not iterable Can you add empty %prep and %build sections?
Hmm, I certainly could, but does it really make sense? What kind of input do you expect from fedora-review? The package has two files, and I really doubt that fedora-review will have anything unexpected to say. I don't think I should make the package more complicated just to work around bugs in fedora-review, this is not the job of the submitter. If you really want to call fedora-review, maybe just apply the workarounds locally? (Or in other words: if I add those to pass review, I'll immediately remove the afterwards anyway.)
Meh, fair point... At this point, I guess it's fine now. PACKAGE APPROVED.
Status update: I didn't build this yet, because we need to figure out details of updates and signing. I guess some work in 'bootctl update' will be necessary. I want to only do scratch builds of this package until that is resolved, and until signing is configured.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #11) > (In reply to Neal Gompa from comment #8) > > * The systemd-boot-unsigned and systemd-boot packages should have their efi > > architectures as suffixes, similar to shim and grub > > Hmm, but why? I don't see any guideline that'd require this, and it makes > things more complicated. Can we also make the packages noarch please, simliar to edk2? That way I can -- for example -- install the aarch64 package on a x86_64 machine and use the efi stubs when cross-compiling kernels.
> Can we also make the packages noarch please, simliar to edk2? The package is archful because it takes systemd-udev or systemd-boot-unsigned from the systemd build and "repackages" it. To make it noarch, we'd need to be able to access packages for all architectures, which I don't know how to do. I think our build system doesn't really support this. If you have an idea how to do this, please submit a PR against https://src.fedoraproject.org/rpms/systemd-boot. -- I pushed the sources to the dist-git repo now. I'm still not building the package because signing hasn't been set up. But I'll close this ticket. The review is done.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #33) > > Can we also make the packages noarch please, simliar to edk2? > > The package is archful because it takes systemd-udev or systemd-boot-unsigned > from the systemd build and "repackages" it. Oh, this is just the signing package. What is the plan for the unsigned packages? The stub would not be signed anyway and that is the more interesting case for cross-builds. Can we have noarch systemd-boot-unsigned-${efiarch} subpackages with sd-boot + sd-stub?
> Can we have noarch systemd-boot-unsigned-${efiarch} subpackages with sd-boot + sd-stub? I assume that you mean availability of a full set of systemd-boot-unsigned-{x64,ia32,aa64}.noarch on every architecture. I looked into this, and I don't see a way to do this in the current scheme of things. sd-boot is compiled against gnu-efi.{x86_64,i686,aarch64}. Our build infrastructure requires that all noarch packages are the same. So we'd need to build the arm64 variant on amd64 and vice versa. But the gnu-efi package for the foreign architecture is not available. For now, systemd-boot-unsigned.x86_64 has Provides:systemd-boot-unsigned-x64 and similarly for other architectures. I don't know how to do better at this momement, but as mentioned above, if somebody has a better idea, a pull request would be welcome.
I was looking extensively into this, and I'll write it up before it all evaporates: - there are two source dist-gits: shim-unsigned-aarch64 and shim-unsigned-x64 (this uses the gnu-efi architecture naming convention). Strangely, those packages use different sources, or more precisely speaking, the same %SOURCE0 but with different patchsets and have different Release. We get binary rpms shim-unsigned-aarch64, shim-unsigned-ia32, shim-unsigned-x64. - I'm not sure how that works exactly, but I assume that the .efi files from the unsigned packages are signed via some web service at MS. - shim has various efi binaries as SourceNN: shimaa64.efi, shimia32.efi, shimx64.efi. I assume they are copied into sources after being signed. It builds arch-specific packages: shim-aa64.aarch64, shim-ia32.x86_64, shim-x64.x86_64. I don't understand why the shim (signed) packages are archful. The package could be noarch and build all subpackages and then we would get shim-aa64.noarch, shim-ia32.noarch, shim-x64.noarch on each architecture. To get such a result with systemd-boot, two approaches would be possible: 1. do what shim does, and copy the files by hand from the unsigned rpms to 'sources'. 2. split the source package into systemd-boot-x86_64 and systemd-boot-aarch64, and make the packages BuildArch:noarch. systemd-boot-x86_64 would build systemd-boot-x64.noarch, systemd-boot-ia32.noarch, and systemd-boot-aarch64 would build systemd-boot-aarch64.noarch. The problem is that the builds would fail if scheduled on the wrong architecture, i.e. we'd need to cancel and repeat the builds until the right arch of builder is encountered. This would be fairly terrible. If koji would allow the build arch for noarch packages to be specified, this approach wouldn't be somewhat better. Neither approach is very attractive :(
> 2. split the source package into systemd-boot-x86_64 and > systemd-boot-aarch64, and > make the packages BuildArch:noarch. systemd-boot-x86_64 would build > systemd-boot-x64.noarch, > systemd-boot-ia32.noarch, and systemd-boot-aarch64 would build > systemd-boot-aarch64.noarch. > The problem is that the builds would fail if scheduled on the wrong > architecture, > i.e. we'd need to cancel and repeat the builds until the right arch of > builder is > encountered. This would be fairly terrible. Well. You can have a systemd-boot-x86_64.srpm package which is exclusivearch x86_64 and produces an empty main package plus a systemd-boot-unsigned-x64.noarch subpackage. Ideally you would have a single systemd-boot.srpm which produces systemd-boot-unsigned-x64.noarch when compiled on x86_64 and systemd-boot-unsigned-aa64.noarch when compiled on aarch64, but IIRC that works on RHEL only. One of the annonying build system differences between rhel and fedora.
> You can have a systemd-boot-x86_64.srpm package which is > exclusivearch x86_64 and produces an empty main package plus a > systemd-boot-unsigned-x64.noarch subpackage. OK. We could do that. I don't particularly *like* the idea, but I guess the update+build would be scripted anyway, so doing it for each architecture would be tolerable. A side-tag can be used so that there's just one update in the end. Before starting work on this: is this important / useful enough to justify the effort?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #38) > > You can have a systemd-boot-x86_64.srpm package which is > > exclusivearch x86_64 and produces an empty main package plus a > > systemd-boot-unsigned-x64.noarch subpackage. > > OK. We could do that. I don't particularly *like* the idea, but I guess > the update+build would be scripted anyway, so doing it for each architecture > would be tolerable. A side-tag can be used so that there's just one update > in the end. > > Before starting work on this: is this important / useful enough to justify > the effort? Hmm, I was about to answer 'kernel cross builds' but I suspect 'dracut --uefi' (which needs the stubs from the package) is not going to work for cross builds anyway. So I'd say hold for now, lets wait with this until we have an actual use case.
> I suspect 'dracut --uefi' (which needs the stubs from the package) is not going to work for cross builds anyway. Yeah, that uses objcopy, which for whatever unexplained reasons, only works for the native architecture. The same limitation holds for systemd/ukify, because it also calls objcopy. We were discussing using something else (llvm-objcopy?), but I think it had some other limitations. So at least for now this limitation holds.