Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result:
1. Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use better documentation to help the user perform the volume resize in Windows, before proceeding to booting our installation media. The documentation probably should be explicitly referenced by the Windows version of Fedora Media Writer.
2. The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the boot chain, as is the case in our default dual boot installation, the measurements are wrong, and this means the GRUB menu entry to boot Windows won't work. The user is dropped to a Windows Bitlocker recovery page. If they have their backup encryption key handy, it will work but to say the least this condition is unexpected and not user friendly - not least of which is many users won't have this backup key handy since they didn't take the action to enable Bitlocker in the first place.
The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849
It was a Fedora 36 final release blocking bug, but considered a "difficult to fix" exceptional case, moving it to Fedora 37 final. Some of the options for consideration:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.)
c. Change the release criterion. https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual...
Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora.
Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora.
d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release.
Thoughts?
-- Chris Murphy
Chris Murphy wrote:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows? GRUB would still think it boots Windows directly. (I do not see why it would notice any difference, all that would change is the name of the image that gets chainloaded.) And systemd- boot does not need to know that it is being chainloaded from GRUB. So I do not see why that would not work, without any changes to the software.
Kevin Kofler
On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows?
Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing.
GRUB would still think it boots Windows directly. (I do not see why it would notice any difference, all that would change is the name of the image that gets chainloaded.) And systemd- boot does not need to know that it is being chainloaded from GRUB. So I do not see why that would not work, without any changes to the software.
On Tue, Jul 26, 2022 at 1:12 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows?
Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing.
GRUB would still think it boots Windows directly. (I do not see why it would notice any difference, all that would change is the name of the image that gets chainloaded.) And systemd- boot does not need to know that it is being chainloaded from GRUB. So I do not see why that would not work, without any changes to the software.
Put more directly: Microsoft will revoke our shim if we use anything but GRUB as the stage-two bootloader.
Cf. https://github.com/rhboot/shim/issues/472#issuecomment-1118628769
-- 真実はいつも一つ！/ Always, there's only one truth!
On Di, 26.07.22 13:37, Neal Gompa (ngompa13@gmail.com) wrote:
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows?
Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing.
GRUB would still think it boots Windows directly. (I do not see why it would notice any difference, all that would change is the name of the image that gets chainloaded.) And systemd- boot does not need to know that it is being chainloaded from GRUB. So I do not see why that would not work, without any changes to the software.
Put more directly: Microsoft will revoke our shim if we use anything but GRUB as the stage-two bootloader.
Cf. https://github.com/rhboot/shim/issues/472#issuecomment-1118628769
To state this clearly:
The people I talked to in MSFT do not know of any such requirement. To me, the above comment appears to be FUD.
In fact, the SHIM review guidelines already say this:
"Note that we really only have experience with using GRUB2 on Linux, so asking us to endorse anything else for signing is going to require some convincing on your part."
(from https://github.com/rhboot/shim-review#readme)
Hence, it's the shim people who are not keen on non-grub boot loaders, but even they indicate they can be convinced of other boot loaders.
Given the overlap of the Fedora/RH boot loader folks and the shim folks, I think there's definitely an avenue to get systemd-boot signed as payload for SHIM, as alternative to Grub. If Fedora wants this, and has the man power for it, it should be a quite a reachable goal, given that sd-boot has only a tiny fraction of the code footprint that Grub has.
Lennart
-- Lennart Poettering, Berlin
Sorry for showing up here unannounced.
This is a very strange claim. I'm not speaking in any official capacity but at least __personally__ being at the Linux Systems Group at MSFT I've never have encountered any hard requirement on grub.
In any case, I want to point out a few things:
* Some of the signing requirements as expressed here afaict: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-sign... and it mentions:
If your submission is a SHIM (handing off execution to another bootloader), then you must first submit to the SHIM review board and be approved before a submission will be signed. [...]".
I don't see any requirement that suggeste MSFT would require a specific boot loader.
* MSFT recently published https://docs.microsoft.com/en-us/windows/security/information-protection/sec... and states
The default state of Secure Boot has a wide circle of trust which can result in customers trusting boot components they may not need. Since the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for all Linux distributions, trusting the Microsoft 3rd Party UEFI CA signature in the UEFI database increases the attack surface of systems. A customer who intended to only trust and boot a single Linux distribution will trust all distributions – much more than their desired configuration. A vulnerability in any of the bootloaders exposes the system and places the customer at risk of exploit for a bootloader they never intended to use, as seen in recent vulnerabilities, for example with the GRUB bootloader or firmware-level rootkit affecting boot components. Secured-core PCs require Secure Boot to be enabled and configured to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide customers with the most secure configuration of their PCs possible.
This explicitly mentions the security track record of GRUB as one of the reasons for making this - let's keep it civil and call it controversial - decision of disabling the 3rd part signing key in the BIOS.
* The shim-review repo did approve a shim plus another boot loader for CISCO multiple times. For example, https://github.com/rhboot/shim-review/issues/212
We have no plans to use GRUB2 as a second stage loader. Our intention is to bundle the Linux Kernel, initramfs, and kernel command line into a single EFI binary such that the PE/COFF signature protects all of those components. We are using a small EFI stub, based on the systemd-boot stub, to do this and we have augmented it to add support for a SBAT section. The "stubby" EFI shim: https://github.com/puzzleos/stubby
So just to be very clear their stubby boot loader is a standalone systemd-boot clone...
In light of all this quotes like:
https://github.com/rhboot/shim/issues/472#issuecomment-1118529154:
grub is the only 2nd stage loader that is allowed to be signed with the shim MS trust chain, so it's a bit pointless.
and
https://github.com/rhboot/shim/issues/472#issuecomment-1118628769
Regarding bootloader signing: grub is being signed, signing any additional bootloader increases the attack surface, hence only grub will be signed (the exception is that you can load a kernel directly; you can combine the kernel with systemd-boot stub too, as the entire binary is signed - however, systemd-boot stub is becoming increasingly complex (e.g. sysexts) and at some point one might have to pull the plug on that too and use a fork of an older version).
Note that we only have talked about distributions that already ship grub bootloader. We have not discussed signing alternative bootloaders for new distributions without grub; however, at least systemd-boot and pxelinux are barred from signing in general due to implementation quality concerns fundamental disagreement about how secure boot works.
e.g. if you sign systemd-boot or pxelinux with your key inside the shim, your next shim review will be rejected
Especially "systemd-boot stub is becoming increasingly complex" and "due to implementation quality concerns" is mind-blowlingly ironic and frankly disingenuous.
Once upon a time, Lennart Poettering mzerqung@0pointer.de said:
Given the overlap of the Fedora/RH boot loader folks and the shim folks, I think there's definitely an avenue to get systemd-boot signed as payload for SHIM, as alternative to Grub. If Fedora wants this, and has the man power for it, it should be a quite a reachable goal, given that sd-boot has only a tiny fraction of the code footprint that Grub has.
So, I went to look a little more at systemd-boot/sd-boot... and noticed the packaging is really odd in Fedora. Why is it shoved into the systemd-udev RPM? It seems that systemd-boot should be its own subpackage.
On Do, 28.07.22 10:25, Chris Adams (linux@cmadams.net) wrote:
Once upon a time, Lennart Poettering mzerqung@0pointer.de said:
Given the overlap of the Fedora/RH boot loader folks and the shim folks, I think there's definitely an avenue to get systemd-boot signed as payload for SHIM, as alternative to Grub. If Fedora wants this, and has the man power for it, it should be a quite a reachable goal, given that sd-boot has only a tiny fraction of the code footprint that Grub has.
So, I went to look a little more at systemd-boot/sd-boot... and noticed the packaging is really odd in Fedora. Why is it shoved into the systemd-udev RPM? It seems that systemd-boot should be its own subpackage.
I think this was mostly done because the rpm split originally done was to separate out parts that you need when booting systemd in a container from those which you do not need there. udev/sd-boot is useless in a container, hence it was split out, and was turned into a seperate new rpm, named after one of the most prominent components.
I am not involved in systemd packaging anymore, but I am sure if you make your case on rhbz Zbigniew or so will consider your case.
Lennart
-- Lennart Poettering, Berlin
OK. Happy day, we have maybe come full circle. Here's my attempt at a summary:
* systemd-boot should be evaluated for Secure Boot signing, so that it can be a viable and testable alternative bootloader to GRUB. Maybe this opens the door to changing the default bootloader in Fedora down the road. It already supports modifying the UEFI bootnext variable, followed by a reboot, when choosing Windows from its menu. Thus it could help resolve the Bitlocker issue.
* Unresolved is how to address the current blocker bug
Long term approaches (not Fedora 37, maybe Fedora 38 or beyond):
- fix/enhance GRUB (no interest so far upstream) - use systemd-boot in lieu of GRUB
Short term approaches:
- Documentation: GRUB's Windows boot option may not work, how to use efibootmgr --bootnext and --bootorder
Unknown time frame approaches:
- A GUI utility wrapper for efibootmgr. (The seemingly simple often isn't so simple, or maybe it is. I don't know.)
In the near term, we're looking at an awareness and documentation effort, while seeing how the other options shake out. And it probably doesn't significantly matter whether we change the release criterion now or also wait a bit longer.
ack/nack/patch?
-- Chris Murphy
On Thu, Jul 28, 2022 at 6:52 PM Chris Murphy lists@colorremedies.com wrote:
Short term approaches:
- Documentation: GRUB's Windows boot option may not work, how to use
efibootmgr --bootnext and --bootorder
Currently there is this (insufficient, of course): https://ask.fedoraproject.org/t/windows-with-encrypted-disks-bitlocker-cant-...
I'd like to see some proper guide available in Fedora Docs/Quick Docs/wiki that I could reference from that Common Issue entry.
In the near term, we're looking at an awareness and documentation effort, while seeing how the other options shake out. And it probably doesn't significantly matter whether we change the release criterion now or also wait a bit longer.
We can change the criterion shortly before Final, if needed. Since we expect the situation to improve in the future, we could just add a (temporary) footnote to the existing criterion saying that the special case of Windows partitions encrypted by Bitlocker are exempt from the requirement (of booting Windows from GRUB).
On Fri, Jul 29, 2022, at 4:38 AM, Kamil Paral wrote:
- Documentation: GRUB's Windows boot option may not work, how to use efibootmgr --bootnext and --bootorder
Currently there is this (insufficient, of course): https://ask.fedoraproject.org/t/windows-with-encrypted-disks-bitlocker-cant-...
Looks pretty good actually. What's missing or unclear?
I think we should consider swapping the built-in bootmanager and efibootmgr sections. The efibootmgr section needs enhancement first: how to find the Windows boot entry number; use case 1: do a one time boot of windows with --bootnext; use case 2: persistently make Windows or Fedora the default boot OS with --bootorder; use case 3: boot Fedora from Windows when Windows is the default boot OS. Each with examples and screenshots.
The efibootmgr CLI is a consistent interface for everyone. It's much easier to document concisely. The firmware method defies screenshots or examples. I'd either make it a secondary section or remove it, but have no strong feeling about it.
I'd like to see some proper guide available in Fedora Docs/Quick Docs/wiki that I could reference from that Common Issue entry.
I'd like Ask and Quickdoc to be essentially identical. This no conflicting info between them. Each is a single authoritative source. And each should be updated in parity.
In the near term, we're looking at an awareness and documentation effort, while seeing how the other options shake out. And it probably doesn't significantly matter whether we change the release criterion now or also wait a bit longer.
We can change the criterion shortly before Final, if needed. Since we expect the situation to improve in the future, we could just add a (temporary) footnote to the existing criterion saying that the special case of Windows partitions encrypted by Bitlocker are exempt from the requirement (of booting Windows from GRUB).
One pretty big weakness I missed in the summary: the non-functional Windows menu item in GRUB. That's quite a trap. I'm not sure any documentation adequately addresses this. But I also don't know an easy way to detect this situation and either inhibit creation of or remove this item.
-- Chris Murphy
On Fri, Jul 29, 2022 at 2:32 PM Chris Murphy lists@colorremedies.com wrote:
On Fri, Jul 29, 2022, at 4:38 AM, Kamil Paral wrote:
Currently there is this (insufficient, of course):
https://ask.fedoraproject.org/t/windows-with-encrypted-disks-bitlocker-cant-...
Looks pretty good actually. What's missing or unclear?
The workarounds section is bare bones. It needs to be made into a full proper guide, so that less experienced users can also follow it.
I think we should consider swapping the built-in bootmanager and efibootmgr sections. The efibootmgr section needs enhancement first: how to find the Windows boot entry number; use case 1: do a one time boot of windows with --bootnext; use case 2: persistently make Windows or Fedora the default boot OS with --bootorder; use case 3: boot Fedora from Windows when Windows is the default boot OS. Each with examples and screenshots.
The efibootmgr CLI is a consistent interface for everyone. It's much easier to document concisely. The firmware method defies screenshots or examples. I'd either make it a secondary section or remove it, but have no strong feeling about it.
I believe both approaches should be present, but I don't feel strongly about ordering. When you want to boot a secondary OS (let's say Windows), the firmware option (when it works and you know how to trigger it) feels more natural to me, and is definitely more friendly than asking general users to run a cryptic command in a terminal as root. Also, booting Fedora, logging in and running a command just to be able to get into Windows is not the definition of a smooth experience for me. It would be a bit better with a GUI tool and even better if it could be done from GDM, but still an annoyance in all cases. Pressing e.g. F12 after starting the PC is the fastest way. It all depends how often you need to get to the secondary OS, or whether there are e.g. multiple users, some of them using Fedora and some of them Windows, on the same PC. The preferences can then differ a lot.
I'd like to see some proper guide available in Fedora Docs/Quick Docs/wiki that I could reference from that Common Issue entry.
I'd like Ask and Quickdoc to be essentially identical. This no conflicting info between them. Each is a single authoritative source. And each should be updated in parity.
The Common Issues section on Ask isn't supposed to contain full-length articles, howto's, guides. At least how I imagine it. I'd prefer having a good guide written somewhere (Docs), and just link to it from Common Issues. The purpose of Common Issues is to highlight important and highly visible problems affecting lots of users, provide some links and context and a workaround if available, or a link to a system update when the fix is ready.
If the current situation (can't boot Windows from GRUB on UEFI under certain conditions) becomes a feature instead of a bug, e.g. because we are unable to solve it and we remove the GRUB boot menu on all UEFI machines altogether as proposed, I'd even want it removed from Common Issues. It's really only supposed to document release bugs. General troubleshooting, howto's and guides should be elsewhere. We already somewhat discussed that with Mattdm when people wanted to add e.g. instructions on how to configure the proprietary nvidia driver, etc. It's not a bug -> we should have a separate section for these guides (on Ask/Docs/elsewhere), be it proprietary driver common steps, dual-boot configuration common steps, or anything similar.
One pretty big weakness I missed in the summary: the non-functional Windows menu item in GRUB. That's quite a trap. I'm not sure any documentation adequately addresses this. But I also don't know an easy way to detect this situation and either inhibit creation of or remove this item.
I suppose Anaconda would have to be involved, detect encrypted partitions and provide a hint when the bootloader is created. It would be a static solution, far from ideal, but arguably better than the current state.
On Mon, Aug 1, 2022, at 6:51 AM, Kamil Paral wrote:
I suppose Anaconda would have to be involved, detect encrypted partitions and provide a hint when the bootloader is created. It would be a static solution, far from ideal, but arguably better than the current state.
I think a GRUB patch is needed in the mkconfig scripts, to check for Bitlocker and when present inhibit creation of the Windows boot entry.
The problem with that is it's silent, looks like Windows is missing.
So yeah, also needed is some kind of Anaconda informational message.
-- Chris Murphy
Chris Murphy wrote:
On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows?
Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing.
That is not what I suggested.
I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, systemd-boot would be configured to always reboot to Windows, booting Fedora from GRUB would bypass it entirely), not shim → systemd-boot → Windows.
Kevin Kofler
On Tue, Jul 26, 2022 at 1:43 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Chris Murphy wrote:
On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows?
Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing.
That is not what I suggested.
I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, systemd-boot would be configured to always reboot to Windows, booting Fedora from GRUB would bypass it entirely), not shim → systemd-boot → Windows.
That may work indeed, but we'd need to ensure it can't be used as a stage-two bootloader somehow.
On Tue, Jul 26, 2022, at 4:59 PM, Neal Gompa wrote:
On Tue, Jul 26, 2022 at 1:43 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Chris Murphy wrote:
On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows?
Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing.
That is not what I suggested.
I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, systemd-boot would be configured to always reboot to Windows, booting Fedora from GRUB would bypass it entirely), not shim → systemd-boot → Windows.
That may work indeed, but we'd need to ensure it can't be used as a stage-two bootloader somehow.
Maybe systemd-boot signed with a Fedora key only GRUB provides, and shim does not?
Either shim or GRUB must have this key so regardless we need help from folks who can sign Fedora's bootloaders.
Seems more complicated compared to a user space program that merely does `efibootmgr --bootnext $windows`
On Tue, Jul 26, 2022, at 4:42 PM, Kevin Kofler via devel wrote:
Chris Murphy wrote:
On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows?
Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing.
That is not what I suggested.
I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, systemd-boot would be configured to always reboot to Windows, booting Fedora from GRUB would bypass it entirely), not shim → systemd-boot → Windows.
OK. But still systemd-boot would need to be signed by Fedora. And be capable of defaulting to Windows, and hidden menu, so it doesn't show bootloader snippets on the boot or EFI volumes. I don't know whether it can be configured this way.
It's a Rube Goldberg machine way of doing this. In effect three bootloaders to support. I'm not convinced this is the path of least resistance. But it seems to be worth considering.
Could someone sign systemd-boot please? That EFI boot seems simple to use and very minimal especially for both x64 arch based desktop and laptop.
On 2022-07-26 16:14, Chris Murphy wrote:
On Tue, Jul 26, 2022, at 4:42 PM, Kevin Kofler via devel wrote:
Chris Murphy wrote:
On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows?
Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing.
That is not what I suggested.
I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, systemd-boot would be configured to always reboot to Windows, booting Fedora from GRUB would bypass it entirely), not shim → systemd-boot → Windows.
OK. But still systemd-boot would need to be signed by Fedora. And be capable of defaulting to Windows, and hidden menu, so it doesn't show bootloader snippets on the boot or EFI volumes. I don't know whether it can be configured this way.
It's a Rube Goldberg machine way of doing this. In effect three bootloaders to support. I'm not convinced this is the path of least resistance. But it seems to be worth considering.
On Tue, Jul 26, 2022 at 4:07 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Chris Murphy wrote:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows? GRUB would still think it boots Windows directly. (I do not see why it would notice any difference, all that would change is the name of the image that gets chainloaded.) And systemd- boot does not need to know that it is being chainloaded from GRUB. So I do not see why that would not work, without any changes to the software.
Kevin Kofler
Why wase the cycles trying to outsmart TPM? Why not use a virtualized Fedora in a VM on the Windows box, or vice versa, instead of continuing to burn cycles on what has been a long running source of instability and incompatibility on new hardware and with new bootloaders? If there were anyone actually working on improving the upstream BIOS to handle dual-booting better, I might see it. But I don't see hardware vendors pusuing this. Do you?
On 29 Jul 2022, at 06:53, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Tue, Jul 26, 2022 at 4:07 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Chris Murphy wrote:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
As I already mentioned the last time this has come up: Why can we not, instead of chainloading Windows directly, chainload a systemd-boot configured to always bootnext to Windows? GRUB would still think it boots Windows directly. (I do not see why it would notice any difference, all that would change is the name of the image that gets chainloaded.) And systemd- boot does not need to know that it is being chainloaded from GRUB. So I do not see why that would not work, without any changes to the software.
Kevin KoflerWhy wase the cycles trying to outsmart TPM? Why not use a virtualized Fedora in a VM on the Windows box, or vice versa, instead of continuing to burn cycles on what has been a long running source of instability and incompatibility on new hardware and with new bootloaders? If there were anyone actually working on improving the upstream BIOS to handle dual-booting better, I might see it. But I don't see hardware vendors pusuing this. Do you?
For work I use fedora in a VMware VM under windows 10 and the experience is poor. Sound does not work at all which forces use of windows video conferencing tools. Windows keeps interferring with the multi monitor layout.
I am waiting of work to approve use of fedora without windows.
Barry
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Once upon a time, Chris Murphy lists@colorremedies.com said:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
Is GRUB upstream any more active these days? IIRC Fedora has a whole pile of patches; I'm sure nobody wants the pile to grow, but it doesn't look like that's changing. Could this be implemented in Fedora's GRUB?
On Tue, Jul 26, 2022, at 7:18 PM, Chris Adams wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
Is GRUB upstream any more active these days?
It is but seems there's no interest in this particular issue.
I started a couple threads on this topic previously, but there's not much traction:
https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html https://lists.gnu.org/archive/html/grub-devel/2022-03/msg00227.html
IIRC Fedora has a whole pile of patches; I'm sure nobody wants the pile to grow, but it doesn't look like that's changing. Could this be implemented in Fedora's GRUB?
It's been cut down quit a bit actually. GRUB 2.06 cut the patchset around in half. And GRUB 2.12 release is imminent, which will cut things down farther.
Since the Red Hat bootloader team is pretty swamped as it is, and has indicated it needs to drop BIOS support (in favor of the newly minted BIOS SIG) soon, I'm skeptical the bootloader team has at least the time to work on this, maintain it, and try to push it upstream. Thing is, it really needs upstream to agree to it, because if it's not upstreamed, what's the point? This is an issue that affects all distros and quite a lot of users eventually, as Bitlocker by default becomes more prevalent. Maybe this issue needs more visibility? Behind the handful of lists I've tried so far?
On 7/26/22 21:56, Chris Murphy wrote:
On Tue, Jul 26, 2022, at 7:18 PM, Chris Adams wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
Is GRUB upstream any more active these days?
It is but seems there's no interest in this particular issue.
I started a couple threads on this topic previously, but there's not much traction:
https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html https://lists.gnu.org/archive/html/grub-devel/2022-03/msg00227.html
IIRC Fedora has a whole pile of patches; I'm sure nobody wants the pile to grow, but it doesn't look like that's changing. Could this be implemented in Fedora's GRUB?
It's been cut down quit a bit actually. GRUB 2.06 cut the patchset around in half. And GRUB 2.12 release is imminent, which will cut things down farther.
Since the Red Hat bootloader team is pretty swamped as it is, and has indicated it needs to drop BIOS support (in favor of the newly minted BIOS SIG) soon, I'm skeptical the bootloader team has at least the time to work on this, maintain it, and try to push it upstream. Thing is, it really needs upstream to agree to it, because if it's not upstreamed, what's the point? This is an issue that affects all distros and quite a lot of users eventually, as Bitlocker by default becomes more prevalent. Maybe this issue needs more visibility? Behind the handful of lists I've tried so far?
Time to ask Microsoft to approve a different stage-2 bootloader?
Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM.
[…]
The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR.
So, basically, they set up things without the user's knowledge so that the user's data can only be decrypted from Windows, only when booted directly, and only with Restricted Boot enabled. Does that not fit the definition of ransomware? Treacherous Computing at its finest… Does anyone still believe that all this is about security?
Kevin Kofler
On Tue, Jul 26, 2022, at 9:15 PM, Kevin Kofler via devel wrote:
Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM.
[…]
The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR.
So, basically, they set up things without the user's knowledge so that the user's data can only be decrypted from Windows, only when booted directly, and only with Restricted Boot enabled. Does that not fit the definition of ransomware? Treacherous Computing at its finest… Does anyone still believe that all this is about security?
cryptsetup does have Bitlocker support, so long as you have the recovery key you can unlock and get access to your data, I've tested this.
Bitlocker has nothing to do with Secure Boot.
This is entirely beside the point though, which is to try and make dual boot as useful for users as possible. We want users to be confident about both OS's remain accessible in a discoverable way, without having to jump through hoops.
Chris Murphy wrote:
cryptsetup does have Bitlocker support, so long as you have the recovery key you can unlock and get access to your data, I've tested this.
But you need a recovery key to begin with, because the main key is sealed in the TPM and not visible from anything other than Windows.
So Bitlocker essentially forces Windows on you.
Bitlocker has nothing to do with Secure Boot.
Disabling "Secure" (Restricted) Boot will change the TPM measurements and hence also prevent the key from being unsealed.
https://docs.microsoft.com/en-us/windows/security/information-protection/bit...
So Bitlocker essentially forces Restricted Boot on you.
This is entirely beside the point though, which is to try and make dual boot as useful for users as possible. We want users to be confident about both OS's remain accessible in a discoverable way, without having to jump through hoops.
Sure. Really sad though that we have to work around a broken piece of "security" software that effectively functions like a ransomware.
Where is the outcry about this misfeature?
Setting up Bitlocker behind the user's back, i.e., also without prompting for a passphrase, provides absolutely no security in the event of a stolen notebook because somebody else hitting the power button will NOT change the TPM measurements, the power button is not a fingerprint reader.
Kevin Kofler
On Wed, Jul 27, 2022 at 05:07:39AM +0200, Kevin Kofler via devel wrote:
Chris Murphy wrote:
cryptsetup does have Bitlocker support, so long as you have the recovery key you can unlock and get access to your data, I've tested this.
But you need a recovery key to begin with, because the main key is sealed in the TPM and not visible from anything other than Windows.
So Bitlocker essentially forces Windows on you.
Bitlocker is part of Windows. Sure, cryptsetup supports it, but if you are using cryptsetup already maybe stick with LUKS2?
This is entirely beside the point though, which is to try and make dual boot as useful for users as possible. We want users to be confident about both OS's remain accessible in a discoverable way, without having to jump through hoops.
Sure. Really sad though that we have to work around a broken piece of "security" software that effectively functions like a ransomware.
Where is the outcry about this misfeature?
Not here, thankfully. This is fedora-devel, I consider name-calling other operating systems to be offtopic here.
On Tue, Jul 26, 2022 at 9:16 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM.
[…]
The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR.
So, basically, they set up things without the user's knowledge so that the user's data can only be decrypted from Windows, only when booted directly, and only with Restricted Boot enabled. Does that not fit the definition of ransomware? Treacherous Computing at its finest… Does anyone still believe that all this is about security?
It's DRM, not ransomware. It's locking in, not deleting, your existing access and tying it to specific hardware and software. It was presented originally as a "security feature", but it was pretty clear from day one that it was designed for digital rights management and vendor lock-in.
Nico Kadel-Garcia wrote:
It's DRM, not ransomware.
Sounds to me like "it's not crap, it's poop". ;-)
It's locking in, not deleting, your existing access
It sneakily encrypts your data forcing you to fulfill specific conditions to access it, just like ransomware does.
and tying it to specific hardware and software.
That is DRM-like behavior, yes. But regular DRM does not restrict your own data behind your back. (That does not mean I condone standard DRM though.)
It was presented originally as a "security feature", but it was pretty clear from day one that it was designed for digital rights management and vendor lock-in.
It fits all under the Treacherous Computing scheme. TPM, Restricted Boot, Bitlocker, DRM, etc. are all pieces of the puzzle. Some work together, some are separate, but they are all parts of the overall scheme.
(By the way, the name "Bitlocker" even SOUNDS like a ransomware.)
Kevin Kofler
On Tue, Jul 26, 2022 at 02:05:24PM -0400, Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result:
Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use better documentation to help the user perform the volume resize in Windows, before proceeding to booting our installation media. The documentation probably should be explicitly referenced by the Windows version of Fedora Media Writer.
The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the boot chain, as is the case in our default dual boot installation, the measurements are wrong, and this means the GRUB menu entry to boot Windows won't work. The user is dropped to a Windows Bitlocker recovery page. If they have their backup encryption key handy, it will work but to say the least this condition is unexpected and not user friendly - not least of which is many users won't have this backup key handy since they didn't take the action to enable Bitlocker in the first place.
The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849
It was a Fedora 36 final release blocking bug, but considered a "difficult to fix" exceptional case, moving it to Fedora 37 final. Some of the options for consideration:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.)
c. Change the release criterion. https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual...
Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora.
Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora.
d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release.
Thoughts?
Since you say systemd-boot can already do what we want in this regard:
e. Replace grub for EFI systems with systemd-boot ?
Or at least make systemd-boot a supported option alongside grub for those who need dual boot with Windows
With regards, Daniel
On Wed, Jul 27, 2022, at 4:42 AM, Daniel P. Berrangé wrote:
Since you say systemd-boot can already do what we want in this regard:
e. Replace grub for EFI systems with systemd-boot ?
I wish it were possible. I'm pretty sure the Red Hat bootloader team has no time or interest in it. And there's no upgrade path, because systemd-boot requires a FAT /boot volume. The lack of an upgrade path, I think, is a bigger issue than a system-wide change proposal to: switch to systemd-boot on UEFI, including FAT /boot partition, for new clean installs.
There's quite a lot of GRUB upstream work related to TPM stuff, including measured boot. I have no idea if we're going to use any of that at some point, but it's not something in systemd-boot's realm.
Or at least make systemd-boot a supported option alongside grub for those who need dual boot with Windows
Given resources, I expect it would be more likely to replace GRUB with systemd-boot, on UEFI, than support both. And the likelihood of anything but GRUB I'd put at "very low". I'd like to be wrong but...
On Wed, Jul 27, 2022 at 10:13:57AM -0400, Chris Murphy wrote:
On Wed, Jul 27, 2022, at 4:42 AM, Daniel P. Berrangé wrote:
Since you say systemd-boot can already do what we want in this regard:
e. Replace grub for EFI systems with systemd-boot ?
I wish it were possible. I'm pretty sure the Red Hat bootloader team has no time or interest in it. And there's no upgrade path, because systemd-boot requires a FAT /boot volume. The lack of an upgrade path, I think, is a bigger issue than a system-wide change proposal to: switch to systemd-boot on UEFI, including FAT /boot partition, for new clean installs.
AFAICT, use of /boot is entirely optional, and is ignored if it can't be accessed (due to either not existing, or having an unsupported filesystem type). I've got VMs booting with system-boot where /boot is xfs and systemd-boot pulls the kernel found in /boot/efi.
IIUC, the main reason for the loader to use /boot is if /boot/efi is insufficiently large for storing the kernels, and /boot has greater space. Admittedly this is probably still the key issue for the upgrade scenario, since existing Fedora VMs seem to get a /boot/efi partition that is even smaller than /boot.
There's quite a lot of GRUB upstream work related to TPM stuff, including measured boot. I have no idea if we're going to use any of that at some point, but it's not something in systemd-boot's realm.
The Grub support for the RPM measurements is one of the big reasons for wanting to replace Grub IMHO. Every single statement that is executed from the grub.conf file gets individually measured into the TPM[1]. Writing a policy to validate correctness of the measurement taking into account grub.conf permuations is beyond the bounds of reasonableness. This is a key problem the virt maintainers are facing when trying to figure out how to support confidential virtualization, where we need to measure the boot process. A vastly simplified boot loader like sd-boot + unified kernels is quite appealing in this area.
With regards, Daniel
[1] From a generic Fedora 36 VM under KVM, the grub measurements alone are this:
# tpm2 eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep grub_cmd grub_cmd: set pager=1 grub_cmd: [ -f (hd0,gpt1)/EFI/fedora/grubenv ] grub_cmd: [ -s (hd0,gpt1)/EFI/fedora/grubenv ] grub_cmd: [ ] grub_cmd: set default= grub_cmd: [ xy = xy ] grub_cmd: menuentry_id_option=--id grub_cmd: export menuentry_id_option grub_cmd: [ ] grub_cmd: terminal_output console grub_cmd: [ xy = xy ] grub_cmd: set timeout_style=menu grub_cmd: set timeout=5 grub_cmd: [ -f (hd0,gpt1)/EFI/fedora/user.cfg ] grub_cmd: insmod increment grub_cmd: [ -n -a = 0 ] grub_cmd: insmod part_gpt grub_cmd: insmod xfs grub_cmd: search --no-floppy --fs-uuid --set=root db3c5945-1d59-4309-b022-df1af7727032 grub_cmd: insmod part_gpt grub_cmd: insmod fat grub_cmd: search --no-floppy --fs-uuid --set=boot 5922-59E5 grub_cmd: [ -z ] grub_cmd: set kernelopts=root=UUID=5fd49e99-6297-4880-92ef-bc31aef6d2f0 ro rd.luks.uuid=luks-6806c81d-4169-4e7a-9bbc-c7bf65cabcb2 rhgb quiet grub_cmd: insmod blscfg grub_cmd: blscfg grub_cmd: [ = 1 -o = 1 ] grub_cmd: set menu_hide_ok=0 grub_cmd: [ = 1 ] grub_cmd: [ = 1 ] grub_cmd: set boot_success=0 grub_cmd: save_env boot_success boot_indeterminate grub_cmd: [ xy = xy ] grub_cmd: [ ] grub_cmd: [ -a 0 = 1 ] grub_cmd: [ xy = xy ] grub_cmd: [ ] grub_cmd: [ efi = efi ] grub_cmd: menuentry UEFI Firmware Settings --id uefi-firmware { grub_cmd: [ -f (hd0,gpt1)/EFI/fedora/custom.cfg ] grub_cmd: [ -z (hd0,gpt1)/EFI/fedora -a -f (hd0,gpt1)/EFI/fedora/custom.cfg ] grub_cmd: load_video grub_cmd: [ xy = xy ] grub_cmd: insmod all_video grub_cmd: set gfxpayload=keep grub_cmd: insmod gzio grub_cmd: linux (hd0,gpt2)/vmlinuz-5.17.13-300.fc36.x86_64 root=UUID=5fd49e99-6297-4880-92ef-bc31aef6d2f0 ro rd.luks.uuid=luks-6806c81d-4169-4e7a-9bbc-c7bf65cabcb2 rhgb quiet grub_cmd: initrd (hd0,gpt2)/initramfs-5.17.13-300.fc36.x86_64.img
On Wed, Jul 27, 2022, at 12:11 PM, Daniel P. Berrangé wrote:
On Wed, Jul 27, 2022 at 10:13:57AM -0400, Chris Murphy wrote:
On Wed, Jul 27, 2022, at 4:42 AM, Daniel P. Berrangé wrote:
Since you say systemd-boot can already do what we want in this regard:
e. Replace grub for EFI systems with systemd-boot ?
I wish it were possible. I'm pretty sure the Red Hat bootloader team has no time or interest in it. And there's no upgrade path, because systemd-boot requires a FAT /boot volume. The lack of an upgrade path, I think, is a bigger issue than a system-wide change proposal to: switch to systemd-boot on UEFI, including FAT /boot partition, for new clean installs.
AFAICT, use of /boot is entirely optional, and is ignored if it can't be accessed (due to either not existing, or having an unsupported filesystem type). I've got VMs booting with system-boot where /boot is xfs and systemd-boot pulls the kernel found in /boot/efi.
Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT in order to fulfill the interoperability intent of the spec, because it is a shared $BOOT across all distros.
While some firmware also can read NTFS or HFS+, we're not likely to ever consider using them for $BOOT.
I'm not sure what an XFS /boot would contain when using systemd-boot.
IIUC, the main reason for the loader to use /boot is if /boot/efi is insufficiently large for storing the kernels, and /boot has greater space. Admittedly this is probably still the key issue for the upgrade scenario, since existing Fedora VMs seem to get a /boot/efi partition that is even smaller than /boot.
The main case for XBOOTLDR is dual boot, because we can't control the creation of the ESP. Microsoft and OEMs are still routinely creating 99 MiB ESPs. Otherwise we can have a large ESP, possibly scaled to the size of the drive or possibly extract intent from the user (in a custom partitioning path) about installing additional distros, etc. to reserve the proper amount of space for this shared $BOOT.
There's quite a lot of GRUB upstream work related to TPM stuff, including measured boot. I have no idea if we're going to use any of that at some point, but it's not something in systemd-boot's realm.
The Grub support for the RPM measurements is one of the big reasons for wanting to replace Grub IMHO. Every single statement that is executed from the grub.conf file gets individually measured into the TPM[1]. Writing a policy to validate correctness of the measurement taking into account grub.conf permuations is beyond the bounds of reasonableness. This is a key problem the virt maintainers are facing when trying to figure out how to support confidential virtualization, where we need to measure the boot process. A vastly simplified boot loader like sd-boot + unified kernels is quite appealing in this area.
I don't disagree. But there are Secure Boot impediments that need to be figured out to switch to sd-boot. And I think they need to be explored with the other sd-boot issues in a dedicated thread, because moving to sd-boot is at best Fedora 38 time frame. And the Bitlocker issue needs improvement sooner than that.
On 27/07/2022 18:53, Chris Murphy wrote:
Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT in order to fulfill the interoperability intent of the spec, because it is a shared $BOOT across all distros.
You can use any FS you want with efifs[1].
[1]: https://github.com/pbatard/efifs
On Wed, Jul 27, 2022, at 2:36 PM, Vitaly Zaitsev via devel wrote:
On 27/07/2022 18:53, Chris Murphy wrote:
Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT in order to fulfill the interoperability intent of the spec, because it is a shared $BOOT across all distros.
You can use any FS you want with efifs[1].
Yeah, but it's impractical:
* $BOOT is supposed to be readable by all distros that share $BOOT * efifs drivers must be signed in order to be loaded on UEFI Secure Boot enabled systems * shim is distro specific, and is what provides the key for efifs as well as the 2nd stage bootloader
There are already enough barriers to Boot Loader Spec adoption. But this would be too big a barrier. Again though, I think the sd-boot discussions really need to go in a separate thread so they have the proper visibility rather than being hidden in an rather distinctly unrelated thread. In this thread we need to focus on solutions for the immediate problem of dual boot with Bitlocker enabled.
On 27/07/2022 22:19, Chris Murphy wrote:
- $BOOT is supposed to be readable by all distros that share $BOOT
It will. efifs will be installed to ESP partition.
- efifs drivers must be signed in order to be loaded on UEFI Secure Boot enabled systems
True. But I think Fedora can sign drivers from the efifs package with own keys.
- shim is distro specific, and is what provides the key for efifs as well as the 2nd stage bootloader
I prefer no shim in my computers. I'm using systemd-boot signed by my own CA.
My /boot is ext4 btw. Works great both on desktop and laptop.
On Wed, Jul 27, 2022, at 4:27 PM, Vitaly Zaitsev via devel wrote:
On 27/07/2022 22:19, Chris Murphy wrote:
- $BOOT is supposed to be readable by all distros that share $BOOT
It will. efifs will be installed to ESP partition.
- efifs drivers must be signed in order to be loaded on UEFI Secure Boot enabled systems
True. But I think Fedora can sign drivers from the efifs package with own keys.
- shim is distro specific, and is what provides the key for efifs as well as the 2nd stage bootloader
I prefer no shim in my computers. I'm using systemd-boot signed by my own CA.
That is not a generic solution we can ship in Fedora. Since each distro ships their own shim, they'd each have to ship their own signed fsfs in order to read the shared a non-FAT $BOOT. It's too high a barrier to adoption.
On Mi, 27.07.22 16:50, Chris Murphy (lists@colorremedies.com) wrote:
I prefer no shim in my computers. I'm using systemd-boot signed by my own CA.
That is not a generic solution we can ship in Fedora. Since each distro ships their own shim, they'd each have to ship their own signed fsfs in order to read the shared a non-FAT $BOOT. It's too high a barrier to adoption.
Something we could add relatively easily to sd-boot is that it could look for drivers to load in one of its own PE sections (let's say a new section ".drivers").
Then Fedora could do something like this:
1. build ext4 efifs as UEFI PE binary (→ ext2_x64.efi) 2. build systemd-boot as UEFI PE binary (→ systemd-bootx64.efi) 3. use "objcopy --add-section .drivers=ext2_x64.efi systemd-bootx64.efi systemd-bootx64.withext4.efi" to embedd the ext4 driver inside systemd-boot 4. sign the resulting systemd-bootx64.withext4.efi via shim/… 5. profitt! now you have an sd-boot binary that can do ext4. yay. 6. ask relevant other distros to do the same. They are probably in a very similar situation as fedora is, given they typically all use Grub right now.
Lennart
-- Lennart Poettering, Berlin
On Wed, Jul 27, 2022 at 2:05 PM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 27.07.22 16:50, Chris Murphy (lists@colorremedies.com) wrote:
I prefer no shim in my computers. I'm using systemd-boot signed by my own CA.
That is not a generic solution we can ship in Fedora. Since each distro ships their own shim, they'd each have to ship their own signed fsfs in order to read the shared a non-FAT $BOOT. It's too high a barrier to adoption.
Something we could add relatively easily to sd-boot is that it could look for drivers to load in one of its own PE sections (let's say a new section ".drivers").
Then Fedora could do something like this:
- build ext4 efifs as UEFI PE binary (→ ext2_x64.efi)
- build systemd-boot as UEFI PE binary (→ systemd-bootx64.efi)
- use "objcopy --add-section .drivers=ext2_x64.efi systemd-bootx64.efi systemd-bootx64.withext4.efi" to embedd the ext4 driver inside systemd-boot
- sign the resulting systemd-bootx64.withext4.efi via shim/…
- profitt! now you have an sd-boot binary that can do ext4. yay.
- ask relevant other distros to do the same. They are probably in a very similar situation as fedora is, given they typically all use Grub right now.
This sounds pretty awesome, actually. I'd like to see that get implemented...
V Thu, Jul 28, 2022 at 06:31:55AM -0700, Neal Gompa napsal(a):
On Wed, Jul 27, 2022 at 2:05 PM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 27.07.22 16:50, Chris Murphy (lists@colorremedies.com) wrote:
I prefer no shim in my computers. I'm using systemd-boot signed by my own CA.
That is not a generic solution we can ship in Fedora. Since each distro ships their own shim, they'd each have to ship their own signed fsfs in order to read the shared a non-FAT $BOOT. It's too high a barrier to adoption.
Something we could add relatively easily to sd-boot is that it could look for drivers to load in one of its own PE sections (let's say a new section ".drivers").
Then Fedora could do something like this:
- build ext4 efifs as UEFI PE binary (→ ext2_x64.efi)
- build systemd-boot as UEFI PE binary (→ systemd-bootx64.efi)
- use "objcopy --add-section .drivers=ext2_x64.efi systemd-bootx64.efi systemd-bootx64.withext4.efi" to embedd the ext4 driver inside systemd-boot
- sign the resulting systemd-bootx64.withext4.efi via shim/…
- profitt! now you have an sd-boot binary that can do ext4. yay.
- ask relevant other distros to do the same. They are probably in a very similar situation as fedora is, given they typically all use Grub right now.
This sounds pretty awesome, actually. I'd like to see that get implemented...
Unfortunatelly (complex) file system drivers are not written with safety on mind. They rather prefer performance over security. If somebody signed a UEFI driver for ext4, there would be a storm of CVEs "Secure boot bypass with a contrived file system".
-- Petr
On Do, 28.07.22 16:54, Petr Pisar (ppisar@redhat.com) wrote:
This sounds pretty awesome, actually. I'd like to see that get implemented...
Unfortunatelly (complex) file system drivers are not written with safety on mind. They rather prefer performance over security. If somebody signed a UEFI driver for ext4, there would be a storm of CVEs "Secure boot bypass with a contrived file system".
efifs just added uefi glue on top of grub's fs drivers.
Thus, if grub is fine to sign, then efifs is much much less risk, given it's a fraction of the grub codebase, but actually mostly code from the grub codebase.
But anyway, I am actually advocating for sticking to VFAT everywhere. ext4 drivers in the boot loader only are necessary for the upgrade path.
Lennart
-- Lennart Poettering, Berlin
On Thu, Jul 28, 2022 at 10:40 AM Lennart Poettering mzerqung@0pointer.de wrote:
...
But anyway, I am actually advocating for sticking to VFAT everywhere. ext4 drivers in the boot loader only are necessary for the upgrade path.
I'd like to 2nd the motion to try to stick with VFAT in the boot path until real/official Linux file system drivers in the kernel/initramfs take over. Trying to maintain several parallel copies of the FS drivers in the bootloader always seemed like a bad idea to me (and a security concern as was pointed out earlier). I'm not even sure it is necessary for an upgrade path. Since the /boot partition is relatively small (even smaller if you stip out the grub stuff) and maintained by scripts anyway, it seems like it *ought* to be possible to automatically convert it or to create a new VFAT-formatted version of the partition somewhere and perhaps leave the old one as a (temporary) failback. Besides the bootloader itself, all that is really on the /boot partition is the kernel and initramfs right?
Also, this might be a little off-topic, but I've recommend that people use systemd-boot when trying to dual-boot Windows before: https://ask.fedoraproject.org/t/dual-booting-windows-10-and-fedora-34/14158/... The user reported that they were happy with that solution later on in that thread, but one annoyance I have is that it requires setting a "SYSTEMD_RELAX_XBOOTLDR_CHECKS" variable before running "bootctl install". Is that really necessary? Why does the /boot partition require a distinct GPT type code? The /boot partition existed long before GPT and its type codes, so this seems a strange requirement (having a separate /boot was a common practice decades ago because the older BIOSes couldn't bootloaders that were placed beyond cylinder 1024 on the disk; it was also common to format /boot with FAT back then because syslinux liked to use that). I'd like to request that systemd-boot "automatically" accept/recognize a merged ESP+XBOOTLDR partition without having to set that special variable.
Thanks.
On Thu, Jul 28, 2022, at 2:05 PM, Gregory Bartholomew wrote:
Also, this might be a little off-topic, but I've recommend that people use systemd-boot when trying to dual-boot Windows before: https://ask.fedoraproject.org/t/dual-booting-windows-10-and-fedora-34/14158/... The user reported that they were happy with that solution later on in that thread, but one annoyance I have is that it requires setting a "SYSTEMD_RELAX_XBOOTLDR_CHECKS" variable before running "bootctl install". Is that really necessary?
The purpose of XBOOTLDR, "shared $boot" is sufficiently different purpose than "dedicated $boot" to warrant differentiation with unique partition type GUIDs. That's the purpose of partition type GUIDs.
I'd like to request that systemd-boot "automatically" accept/recognize a merged ESP+XBOOTLDR partition without having to set that special variable.
Seems to me the only valid type code for a merged ESP+XBOOTLDR is ESP. What am I missing?
-- Chris Murphy
On Thu, Jul 28, 2022 at 1:34 PM Chris Murphy lists@colorremedies.com wrote:
Seems to me the only valid type code for a merged ESP+XBOOTLDR is ESP. What am I missing?
Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR so that the firmware will pick it up properly. The only problem is when using the bootctl command to initialize that partition (/boot), it requires that I set the SYSTEMD_RELAX_XBOOTLDR_CHECKS variable. I don't think it should require setting that environment variable in that case. But maybe I'm using the command incorrectly? The command I'm running is:
SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot --esp-path=/boot
I think you have to set both "--boot-path" and "--esp-path" to the same value to get the merged partition. If I leave off "--boot-path", then I don't have to set the variable. But I'm not sure that it will configure everything correctly in that case. Will it?
On Thu, Jul 28, 2022, at 2:47 PM, Gregory Bartholomew wrote:
On Thu, Jul 28, 2022 at 1:34 PM Chris Murphy lists@colorremedies.com wrote:
Seems to me the only valid type code for a merged ESP+XBOOTLDR is ESP. What am I missing?
Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR so that the firmware will pick it up properly. The only problem is when using the bootctl command to initialize that partition (/boot), it requires that I set the SYSTEMD_RELAX_XBOOTLDR_CHECKS variable. I don't think it should require setting that environment variable in that case. But maybe I'm using the command incorrectly? The command I'm running is:
SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot --esp-path=/boot
omit --boot-path and have only an --esp-path
I think you have to set both "--boot-path" and "--esp-path" to the same value to get the merged partition. If I leave off "--boot-path", then I don't have to set the variable. But I'm not sure that it will configure everything correctly in that case. Will it?
It should. BLS envisions two configurations: ESP only, contains all files; ESP contains bootloaders, XBOOTLDR contains /loader/entries and everything else. There isn't really a concept of one partition being both ESP and XBOOTLDR.
An argument could be made in favor of two ESPs instead of an ESP and XBOOTLDR, but whatever. I'm not going to make it.
-- Chris Murphy
On Do, 28.07.22 15:03, Chris Murphy (lists@colorremedies.com) wrote:
Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR so that the firmware will pick it up properly. The only problem is when using the bootctl command to initialize that partition (/boot), it requires that I set the SYSTEMD_RELAX_XBOOTLDR_CHECKS variable. I don't think it should require setting that environment variable in that case. But maybe I'm using the command incorrectly? The command I'm running is:
SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot --esp-path=/boot
omit --boot-path and have only an --esp-path
Correct.
I think you have to set both "--boot-path" and "--esp-path" to the same value to get the merged partition. If I leave off "--boot-path", then I don't have to set the variable. But I'm not sure that it will configure everything correctly in that case. Will it?
It should. BLS envisions two configurations: ESP only, contains all files; ESP contains bootloaders, XBOOTLDR contains /loader/entries and everything else. There isn't really a concept of one partition being both ESP and XBOOTLDR.
An argument could be made in favor of two ESPs instead of an ESP and XBOOTLDR, but whatever. I'm not going to make it.
One is not really supposed to have multiple ESPs on the same medium. Firmware should use the first one only, and ignore the other, but you know how firmware is, when it finds unexpected stuff...
Lennart
-- Lennart Poettering, Berlin
On Thu, Jul 28, 2022 at 3:17 PM Lennart Poettering mzerqung@0pointer.de wrote:
On Do, 28.07.22 15:03, Chris Murphy (lists@colorremedies.com) wrote:
Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR
so that the firmware will pick it up properly. The only problem is when using the bootctl command to initialize that partition (/boot), it requires that I set the SYSTEMD_RELAX_XBOOTLDR_CHECKS variable. I don't think it should require setting that environment variable in that case. But maybe I'm using the command incorrectly? The command I'm running is:
SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot
--esp-path=/boot
omit --boot-path and have only an --esp-path
Correct.
I just tested omitting --boot-path and it does seem to be putting all the content under /boot. So it is my bad for misunderstanding how the bootctl parameters were supposed to be provided. Thanks!
... One is not really supposed to have multiple ESPs on the same medium. ...
That "on the same medium" is an interesting caveat. I've been trying to do A/B type configurations where there are two (or more) ESPs on redundant "system" drives (one per drive). I'm still not sure that it is officially supported. But it seems like it ought to be. But I guess I'm way off topic from the purpose of this thread. I look forward to Fedora Linux fixing its multiboot problems by switching to systemd-boot. :)
On Do, 28.07.22 17:18, Gregory Bartholomew (gregory.lee.bartholomew@gmail.com) wrote:
One is not really supposed to have multiple ESPs on the same medium. ...
That "on the same medium" is an interesting caveat. I've been trying to do A/B type configurations where there are two (or more) ESPs on redundant "system" drives (one per drive). I'm still not sure that it is officially supported. But it seems like it ought to be. But I guess I'm way off topic from the purpose of this thread. I look forward to Fedora Linux fixing its multiboot problems by switching to systemd-boot. :)
Having one ESP on each individual medium is fine. The firmware will boot into the ESP that is configured in the EFI boot variables, or if none is configured into the one that is found on the boot medium that is found first according to your firmware's boot medium order.
Lennart
-- Lennart Poettering, Berlin
Am 28.07.2022 um 22:17 schrieb Lennart Poettering mzerqung@0pointer.de:
One is not really supposed to have multiple ESPs
I have another question regarding multiple ESPs, maybe a bit off-topic. For software raid we currently have a kind of „off-label use“. Anaconda puts the ESP on a raid partition (and the /boot partition as well) and so the partition is marked as RAID and not as ESP. I know, there are several alternatives in development to synchronise ESP partitions, but none is included in Anaconda. And maybe none of the alternatives is ready for production. How does this fit into the plans being discussed here? It is an important issue for Fedora Server.
On Fr, 29.07.22 00:21, Peter Boy (pboy@uni-bremen.de) wrote:
One is not really supposed to have multiple ESPs
I have another question regarding multiple ESPs, maybe a bit off-topic. For software raid we currently have a kind of „off-label use“. Anaconda puts the ESP on a raid partition (and the /boot partition as well) and so the partition is marked as RAID and not as ESP. I know, there are several alternatives in development to synchronise ESP partitions, but none is included in Anaconda. And maybe none of the alternatives is ready for production. How does this fit into the plans being discussed here? It is an important issue for Fedora Server.
That's a terrible idea. UEFI file system drivers are read/write. sd-boot makes use of that even, to implement boot counting/automatic fallback (which I am sure is stuff you *really* want in attended systems that shall be able to safely come back when rebooted).
Given that firmware and uefi programs can and do write through the official sanctioned UEFI APIs to the ESP using RAID on ESP is a really bad idea — unless the firmware also implements your flavour of RAID. But it would be news to me that firmwares exist that support Linux software RAID natively.
ESP is defined the way it is, you cannot reinvent its storage underpinnings without breaking the other players that might access the ESP, i.e. firmware, boot loaders, other dual boot OSes. If you want to replicate the ESP, do so by synchronizing contents from userspace maybe. But even that is unreliable, since you can't necessarily trust mtimes there, to figure out what is newer...
I mean, my understanding is that you want to increase reliability by having a working ESP around on multiple disks. But by doing such off-label use stuff you just create problems for yourself that decrease realiability.
Lennart
-- Lennart Poettering, Berlin
On Fri, Jul 29, 2022, at 5:25 AM, Lennart Poettering wrote:
On Fr, 29.07.22 00:21, Peter Boy (pboy@uni-bremen.de) wrote:
One is not really supposed to have multiple ESPs
I have another question regarding multiple ESPs, maybe a bit off-topic. For software raid we currently have a kind of „off-label use“. Anaconda puts the ESP on a raid partition (and the /boot partition as well) and so the partition is marked as RAID and not as ESP. I know, there are several alternatives in development to synchronise ESP partitions, but none is included in Anaconda. And maybe none of the alternatives is ready for production. How does this fit into the plans being discussed here? It is an important issue for Fedora Server.
That's a terrible idea. UEFI file system drivers are read/write.
The built-in FAT driver is rw. The efifs drivers (via GRUB) are ro.
Yes it's a terrible idea. I've mentioned this many times elsewhere it's come up. I'm not sure whether the loophole to use mdadm RAID1 for ESP is still in Anaconda. Originally it was added, as I understand it, because a RHEL customer requested it.
Given that firmware and uefi programs can and do write through the official sanctioned UEFI APIs to the ESP using RAID on ESP is a really bad idea — unless the firmware also implements your flavour of RAID. But it would be news to me that firmwares exist that support Linux software RAID natively.
Intel IMSM format is supported by Linux software RAID. You can use Intel firmware RAID a.k.a. fake-RAID for this. Or any firmware RAID using a format supported by mdadm including DDF.
Otherwise, right now, the sync use case is in bootupd's court.
I mean, my understanding is that you want to increase reliability by having a working ESP around on multiple disks. But by doing such off-label use stuff you just create problems for yourself that decrease realiability.
Yep. Software RAID to increase uptime following failure is OK. But degraded boot is fraught with problems and unreliability. I don't think it should be a requirement for any Fedora product.
On Do, 28.07.22 13:05, Gregory Bartholomew (gregory.lee.bartholomew@gmail.com) wrote:
VFAT-formatted version of the partition somewhere and perhaps leave the old one as a (temporary) failback. Besides the bootloader itself, all that is really on the /boot partition is the kernel and initramfs right?
Pretty much, yes.
Also, this might be a little off-topic, but I've recommend that people use systemd-boot when trying to dual-boot Windows before: https://ask.fedoraproject.org/t/dual-booting-windows-10-and-fedora-34/14158/... The user reported that they were happy with that solution later on in that thread, but one annoyance I have is that it requires setting a "SYSTEMD_RELAX_XBOOTLDR_CHECKS" variable before running "bootctl install". Is that really necessary? Why does the /boot partition require a distinct GPT type code?
The boot loader needs a way to find the file systems to look into. It does so by scanning the GPT table, to find a suitable partition, and the GPT partition type we use is the indicator for "suitable" partition.
Note that the sdboot from UEFI mode has no access to your /etc/fstab, i.e. it doesn't know that you might mount some generic partition to /boot/. Thus it needs another way to recognize the partition. That's why you have to set the GPT partitoin type to XBOOTLDR.
The /boot partition existed long before GPT and its type codes, so this seems a strange requirement (having a separate /boot was a common practice decades ago because the older BIOSes couldn't bootloaders that were placed beyond cylinder 1024 on the disk; it was also common to format /boot with FAT back then because syslinux liked to use that). I'd like to request that systemd-boot "automatically" accept/recognize a merged ESP+XBOOTLDR partition without having to set that special variable.
sd-boot looks for menu items in the ESP, as well as the XBOOTLDR partition, if it exists. There's no need to "merge" ESP with XBOOTLR, because everything you could place in XBOOTLDR you can as well put in the ESP *anyway* if space permits it, since sd-boot checks both place. (The reverse is not true however, certain specific things can only be placed on the ESP, and not in XBOOTLDR, most prominently any fs drivers that are needed to access the XBOOTLDR partition should it not be VFAT)
Lennart
-- Lennart Poettering, Berlin
On Mi, 27.07.22 16:19, Chris Murphy (lists@colorremedies.com) wrote:
Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT in order to fulfill the interoperability intent of the spec, because it is a shared $BOOT across all distros.
You can use any FS you want with efifs[1].
Yeah, but it's impractical:
- $BOOT is supposed to be readable by all distros that share $BOOT
Hmm, afaik fedora installs /boot/ currently as ext4, no? *Every* Linux OS should be able to mount that...
- efifs drivers must be signed in order to be loaded on UEFI Secure Boot enabled systems
Well, if fedora can sign a kernel PE image it can also sign an efifs PE image.
The efifs code stems from Grub fs drivers. It's not new code. It's a small part of Grub code that has been considered to be good enough in the Grub status quo hence should not require major re-review when loaded as EFI module instead.
- shim is distro specific, and is what provides the key for efifs as well as the 2nd stage bootloader
There are already enough barriers to Boot Loader Spec adoption. But this would be too big a barrier.
Dunno. The fedora EFI signing infra shouldn't care if you give it a PE kernel image to sign or a PE efifs driver. I mean, the devil is certainly in the detail, but conceptionally these are not new codepaths, but new payloads used in existing codepaths.
Lennart
-- Lennart Poettering, Berlin
On Wed, Jul 27, 2022, at 4:47 PM, Lennart Poettering wrote:
On Mi, 27.07.22 16:19, Chris Murphy (lists@colorremedies.com) wrote:
Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT in order to fulfill the interoperability intent of the spec, because it is a shared $BOOT across all distros.
You can use any FS you want with efifs[1].
Yeah, but it's impractical:
- $BOOT is supposed to be readable by all distros that share $BOOT
Hmm, afaik fedora installs /boot/ currently as ext4, no? *Every* Linux OS should be able to mount that...
I'm talking about distro bootloaders being able to read $BOOT in the pre-boot environment.
If Fedora decides $BOOT Is ext4, that binds other distros looking to adopt BLS into shipping signed efifs ext4 too, in order to use the same $BOOT format we are. Or else, ignore our XBOOTLDR and create their own, in which case we're right back to square one, which is mutually exclusive /boot, no sharing or cooperation between distros.
On Mi, 27.07.22 17:15, Chris Murphy (lists@colorremedies.com) wrote:
On Wed, Jul 27, 2022, at 4:47 PM, Lennart Poettering wrote:
On Mi, 27.07.22 16:19, Chris Murphy (lists@colorremedies.com) wrote:
Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT in order to fulfill the interoperability intent of the spec, because it is a shared $BOOT across all distros.
You can use any FS you want with efifs[1].
Yeah, but it's impractical:
- $BOOT is supposed to be readable by all distros that share $BOOT
Hmm, afaik fedora installs /boot/ currently as ext4, no? *Every* Linux OS should be able to mount that...
I'm talking about distro bootloaders being able to read $BOOT in the pre-boot environment.
If Fedora decides $BOOT Is ext4, that binds other distros looking to adopt BLS into shipping signed efifs ext4 too, in order to use the same $BOOT format we are. Or else, ignore our XBOOTLDR and create their own, in which case we're right back to square one, which is mutually exclusive /boot, no sharing or cooperation between distros.
Well, boot loader spec is *already* used by fedora on ext4. So you are describing the status quo?
I mean, I for one would always suggest people to use the spec on vfat only, and not bother with ext4, so that it is truly universally accessible. But that is simply not what Fedora chose to do, and instead put it on ext4. Not we need to find reasonable compatible ways to support that for existing installations, but not more.
For future installations we can all just do boot loader spec on vfat and all distros will be jolly.
Lennart
-- Lennart Poettering, Berlin
On Mi, 27.07.22 10:13, Chris Murphy (lists@colorremedies.com) wrote:
Since you say systemd-boot can already do what we want in this regard:
e. Replace grub for EFI systems with systemd-boot ?
I wish it were possible. I'm pretty sure the Red Hat bootloader team has no time or interest in it. And there's no upgrade path, because systemd-boot requires a FAT /boot volume.
That's only half the truth. sd-boot searches for kernels on the ESP (which has to be VFAT effectively, since that is the only thing UEFI requires firmwares to support), or on an optional, second partition we call XBOOTLDR which is more like fedora's /boot/ – and that one can be basically any file system, the only requirement is that it must be readable via UEFI file system APIs. VFAT qualifies for that out of the box, hence is a good choice. That said, it's not the only option, there are multiple projects supporting other file systems in UEFI, for example this one:
So, let's say you want to make sd-boot be able to access a legacy ext4 /boot/ fs. First, fix the GPT partition type of that /boot/ partition to be the XBOOTLDR one (so that sd-boot can recognize it; currently fedora for some reason marks it as "generic Linux partition"). Then take the ext4 uefi driver from the project above, sign it as you sign every EFI binary, and drop it into the /EFI/systemd/drivers/ directory on the ESP. This is all you need to do, as sd-boot looks into that dir, and automatically loads all drivers found there.
Net effect: "bootctl install" (the tool that installs sd-boot for you) installs two EFI binaries instead of just one.
Given that the project above simply uses the Grub file system implementations and adds a bit of uefi glue on top, you would actually use the exact same code to access the file systems as before in the Grub case.
That all said: I am pretty sure using non-vfat for XBOOTLDR should be a legacy thing. New installations should use vfat for ESP + XBOOTLDR, to minimize complexity.
Given that fedora already generates Boot Loader Spec entries sd-boot should otherwise be ready to just read what is already there.
The lack of an upgrade path, I think, is a bigger issue than a system-wide change proposal to: switch to systemd-boot on UEFI, including FAT /boot partition, for new clean installs.
I don't think the upgrade path would be so bad. Takes some careful work to get into place, but we went through worse migrations in Fedora I am sure.
There's quite a lot of GRUB upstream work related to TPM stuff, including measured boot. I have no idea if we're going to use any of that at some point, but it's not something in systemd-boot's realm.
Frankly, the TPM and grub situation is a giant mess. The PCR measurements it generates measure chosen code execution paths, not static code, and hence are entirely useless if you want to reliably precalulate PCR values, and bind policy to that. It's one of the reasons why outside of fixed-purpose systems with a limited scope noone does TPM on Linux.
With systemd-boot/systemd-stub we have more reliable measurements already (we measure code, not chosen code execution paths), which means there are some projects (such as ubuntu core, which currently chainload sd-boot from grub, just to be able to get the realiable TPM measurements we provide you with...).
Lennart
-- Lennart Poettering, Berlin
On Wed, Jul 27, 2022, at 4:30 PM, Lennart Poettering wrote:
So, let's say you want to make sd-boot be able to access a legacy ext4 /boot/ fs. First, fix the GPT partition type of that /boot/ partition to be the XBOOTLDR one (so that sd-boot can recognize it; currently fedora for some reason marks it as "generic Linux partition"). Then take the ext4 uefi driver from the project above, sign it as you sign every EFI binary, and drop it into the /EFI/systemd/drivers/ directory on the ESP. This is all you need to do, as sd-boot looks into that dir, and automatically loads all drivers found there.
Works for single distro installation, sure. But the intent and promise of BLS is distro interoperability with a shared $BOOT among multiple distros.
If the additional barrier to adoption that Fedora imposes is that every distro needs to also include signed efifs ext4 in order to read $BOOT, I think it's too much.
But also we need verification and clarification on this "GRUB only" proscription by Microsoft of any other bootloader, mentioned earlier in this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Mi, 27.07.22 17:01, Chris Murphy (lists@colorremedies.com) wrote: 65;6800;1c
On Wed, Jul 27, 2022, at 4:30 PM, Lennart Poettering wrote:
So, let's say you want to make sd-boot be able to access a legacy ext4 /boot/ fs. First, fix the GPT partition type of that /boot/ partition to be the XBOOTLDR one (so that sd-boot can recognize it; currently fedora for some reason marks it as "generic Linux partition"). Then take the ext4 uefi driver from the project above, sign it as you sign every EFI binary, and drop it into the /EFI/systemd/drivers/ directory on the ESP. This is all you need to do, as sd-boot looks into that dir, and automatically loads all drivers found there.
Works for single distro installation, sure. But the intent and promise of BLS is distro interoperability with a shared $BOOT among multiple distros.
If the additional barrier to adoption that Fedora imposes is that every distro needs to also include signed efifs ext4 in order to read $BOOT, I think it's too much.
I do not follow that logic. First of all, if they can sign grub or sd-boot they should be able to sign efifs too. Secondly, they could just embedd the relevant efifs driver in the sd-boot binary, and sign the result (see other mail). Hence, you build two binaries. Make one of them. Sign one binary.
Lennart
-- Lennart Poettering, Berlin
On Wed, Jul 27, 2022, at 5:07 PM, Lennart Poettering wrote:
On Mi, 27.07.22 17:01, Chris Murphy (lists@colorremedies.com) wrote: 65;6800;1c
If the additional barrier to adoption that Fedora imposes is that every distro needs to also include signed efifs ext4 in order to read $BOOT, I think it's too much.
I do not follow that logic. First of all, if they can sign grub or sd-boot they should be able to sign efifs too. Secondly, they could just embedd the relevant efifs driver in the sd-boot binary, and sign the result (see other mail). Hence, you build two binaries. Make one of them. Sign one binary.
Sure. But all the distros need to support and build efifs drivers in order to support at least common $BOOT file systems across all of Linux, if they're really truly committed to BLS, if not arbitrary file systems.
There's at least ext4, XFS, Btrfs widely used as $BOOT by default these days. But more when looking at what distro installers allow /boot to be: f2fs, ZFS, LUKS, LVM...
Seems like a Pandora's box to me.
On Wed, Jul 27, 2022 at 17:37 Chris Murphy lists@colorremedies.com wrote:
On Wed, Jul 27, 2022, at 5:07 PM, Lennart Poettering wrote:
On Mi, 27.07.22 17:01, Chris Murphy (lists@colorremedies.com) wrote: 65;6800;1c
If the additional barrier to adoption that Fedora imposes is that every distro needs to also include signed efifs ext4 in order to read $BOOT, I think it's too much.
I do not follow that logic. First of all, if they can sign grub or sd-boot they should be able to sign efifs too. Secondly, they could just embedd the relevant efifs driver in the sd-boot binary, and sign the result (see other mail). Hence, you build two binaries. Make one of them. Sign one binary.
Sure. But all the distros need to support and build efifs drivers in order to support at least common $BOOT file systems across all of Linux, if they're really truly committed to BLS, if not arbitrary file systems.
There's at least ext4, XFS, Btrfs widely used as $BOOT by default these days. But more when looking at what distro installers allow /boot to be: f2fs, ZFS, LUKS, LVM...
Seems like a Pandora's box to me.
But isn’t what you are outlining an existing Pandora’s box you are going to have to deal with? All those systems are existing already and will be in place. Telling all couple hundred thousand dual boosters you have to reformat a partition to play with the new thing is also a high bar to deal with.
There is also going to be issues where various windows software is going to see this mountable partition and play with it. Going from past experience every anti virus will freak out at least once a month over seeing Linux executables on a fat partition and quarantine them.
Yes your system is easier to deal with but it is still not as simple as it seems to be seen. It is going to be painful in new ways
-- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Jul 27, 2022, at 9:46 PM, Stephen Smoogen wrote:
On Wed, Jul 27, 2022 at 17:37 Chris Murphy lists@colorremedies.com wrote:
On Wed, Jul 27, 2022, at 5:07 PM, Lennart Poettering wrote:
On Mi, 27.07.22 17:01, Chris Murphy (lists@colorremedies.com) wrote: 65;6800;1c
If the additional barrier to adoption that Fedora imposes is that every distro needs to also include signed efifs ext4 in order to read $BOOT, I think it's too much.
I do not follow that logic. First of all, if they can sign grub or sd-boot they should be able to sign efifs too. Secondly, they could just embedd the relevant efifs driver in the sd-boot binary, and sign the result (see other mail). Hence, you build two binaries. Make one of them. Sign one binary.
Sure. But all the distros need to support and build efifs drivers in order to support at least common $BOOT file systems across all of Linux, if they're really truly committed to BLS, if not arbitrary file systems.
There's at least ext4, XFS, Btrfs widely used as $BOOT by default these days. But more when looking at what distro installers allow /boot to be: f2fs, ZFS, LUKS, LVM...
Seems like a Pandora's box to me.
But isn’t what you are outlining an existing Pandora’s box you are going to have to deal with? All those systems are existing already and will be in place. Telling all couple hundred thousand dual boosters you have to reformat a partition to play with the new thing is also a high bar to deal with.
I'm lost. I'm trying to figure out how Fedora users with Windows Bitlocker enabled, can still boot Windows in a sane way. None of the four ideas I put forward require reformatting anything.
a. Fix/enhance GRUB so it uses "bootnext" and a reboot to directly use the Windows bootloader b. Create a user space utility that can use "bootnext" (optionally also "bootorder" for persistent change) to directly use the Windows bootloader c. Change the release criterion (I don't know that this really gets us off the hook, it's just a plain bad experience even without a criterion) d. Shout from a mountain for more help (punt)
The systemd-boot idea is not one I oppose, but it's not going to happen until Fedora 38 at the soonest, even if someone proposed it, even if it got accepted. It looks to me like a moonshot, thus not that interesting when we have a problem to solve now.
There is also going to be issues where various windows software is going to see this mountable partition and play with it. Going from past experience every anti virus will freak out at least once a month over seeing Linux executables on a fat partition and quarantine them.
As far as I'm aware, Windows ignores GPT partition type GUIDs it doesn't recognize. You have actually experienced what you're describing?
Yes your system is easier to deal with but it is still not as simple as it seems to be seen. It is going to be painful in new ways
Still not sure what the context is.
-- Chris Murphy
On Mi, 27.07.22 17:35, Chris Murphy (lists@colorremedies.com) wrote:
If the additional barrier to adoption that Fedora imposes is that every distro needs to also include signed efifs ext4 in order to read $BOOT, I think it's too much.
I do not follow that logic. First of all, if they can sign grub or sd-boot they should be able to sign efifs too. Secondly, they could just embedd the relevant efifs driver in the sd-boot binary, and sign the result (see other mail). Hence, you build two binaries. Make one of them. Sign one binary.
Sure. But all the distros need to support and build efifs drivers in order to support at least common $BOOT file systems across all of Linux, if they're really truly committed to BLS, if not arbitrary file systems.
There's at least ext4, XFS, Btrfs widely used as $BOOT by default these days. But more when looking at what distro installers allow /boot to be: f2fs, ZFS, LUKS, LVM...
Well, if distributions choose to put boot loader spec drop-ins onto such weird file systems they either didn't understand that the spec is about defining a *shared*, *common* resource, because that way they made it inaccessible to everyone else. Or they did understand it, but simply didn't care.
Whether sd-boot is used to read it, or grub doesn't really matter at that point...
Lennart
-- Lennart Poettering, Berlin
On Wed, Jul 27, 2022 at 10:31 PM Lennart Poettering mzerqung@0pointer.de wrote:
[...]
The lack of an upgrade path, I think, is a bigger issue than a system-wide change proposal to: switch to systemd-boot on UEFI, including FAT /boot partition, for new clean installs.
I don't think the upgrade path would be so bad. Takes some careful work to get into place, but we went through worse migrations in Fedora I am sure.
Indeed, replacing grub2 with sd-boot on an installed Fedora system would just require something like the following commands (assuming that the Secure Boot situation is sorted out somehow):
$ sudo bootctl install $ sudo mkdir /boot/efi/$(cat /etc/machine-id) $ sudo rm -r /boot/loader $ sudo dnf reinstall kernel-core -y
Best regards, Javier
On Tue, Jul 26, 2022 at 8:06 PM Chris Murphy lists@colorremedies.com wrote:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.)
c. Change the release criterion.
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual...
Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora.
Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora.
d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release.
I've been to numerous events where we helped students install Fedora into dual boot. One of the top 5 questions afterwards (maybe even #1) is "how do I make it boot Windows by default?". In the old days, that consisted of editing the grub config file and changing the default selected value to match the Windows boot item, or when "GRUB_DEFAULT=saved" actually worked, I just told them "It will remember the last selected option". That was easy enough and user friendly.
From the proposed options, only a) satisfies that. It is a bit inconvenient that it adds a few more seconds to the boot process (one more reboot), but it can boot Windows by default. If I told them that they must boot Fedora and select something in some menu every time they want to boot Windows (option b)), that would be a gameover. Many of them wouldn't have wanted to install Fedora in such a case. Especially for newcomers, Fedora is just an experiment, a **secondary** option. If we can't deliver that, if we "hijack" their computer and make Fedora the primary system, and make it hard to get into Windows (which they intend to continue using 90% of their time), they'll not want it.
I know that there are other approaches available, like the firmware-based one-time boot menu invoked directly during system startup. But again, for newcomers, if I tell them "the PC will boot Fedora by default, and if you want Windows, you have to press F12 during startup and choose Windows", many of them will not want it. The other way round (boot Windows by default, press F12 to boot Fedora) might be acceptable for them -- this is easy to achieve for power users using efibootmgr after installation, but if Anaconda included such a configuration option, it would be accessible even for less experienced users. There are still issues with this approach, though: 1. I'm not sure if all systems actually support a one-time boot menu. 2. The one-time boot menu key is different on different systems, and it's mostly not advertised during startup, and so you have to figure it out by trial and error (or from a system manual) and remember it. 3. And some systems are configured for a "quick boot" where they actually ignore keyboard input during startup and you can only enter it by using a tool from a booted OS (efibootmgr or a Windows alternative, some Rescue dialog hidden deep in system settings).
While all of us here are happy to run Fedora by default, let's not forget about newcomers and their needs, because our user base will die out otherwise.
So, in the ideal world, a combination of approaches would be accessible. Option a) to support booting Windows by default (or Fedora, or whatever you picked last), and also a userspace graphical utility which would allow users to set the Windows bootloader as default, therefore saving some seconds on each boot. Of course it would include a guide on how to figure out and test the one-time boot menu first, and allow them to change the default bootloader back to Fedora if they wish.
If there's not enough will to implement option a) (or some workaround with the same effect), we'll have to change our release criterion (option c) - I'd probably propose some changes to the wording). I don't see any benefit in delaying the status quo (option d)). But we should also clarify the situation to our users. On the Fedora download page, we should make it clear that users with an encrypted drive will not be able to boot Windows out of the box anymore, and they'll need to take additional steps to get into Windows. That might include a tool in Fedora (option b)), or figuring out how to get to a one-time boot menu. It should also contain instructions on how to switch back to the Windows bootloader by default (after installation, and ideally also as an option during installation), and how to boot Fedora then.
A note: Option b) mentions the Windows boot menu would get removed on UEFI systems - it would be good to do this only if anaconda detects a Bitlocker partition. There's no need to make it harder for Windows users who do not have their disks encrypted.
Thoughts?
On Wed, Jul 27, 2022, at 5:55 AM, Kamil Paral wrote:
I've been to numerous events where we helped students install Fedora into dual boot. One of the top 5 questions afterwards (maybe even #1) is "how do I make it boot Windows by default?". In the old days, that consisted of editing the grub config file and changing the default selected value to match the Windows boot item, or when "GRUB_DEFAULT=saved" actually worked, I just told them "It will remember the last selected option". That was easy enough and user friendly.
From the proposed options, only a) satisfies that.
It could be an option with b) as well. Just change bootorder so that Windows is first. Efibootmgr supports this too.
While all of us here are happy to run Fedora by default, let's not forget about newcomers and their needs, because our user base will die out otherwise.
This is a good point to underscore. The user experience following a Fedora installation when Bitlocker is enabled, is the appearance of Windows being broken or inaccessible. We are probably better off asking Anaconda to refuse to install when Bitlocker is detected. Or at least a warning dialog.
Or perhaps refuse to install just with Automatic partitioning, i.e. accept a somewhat weak argument that users of Custom/Advanced-Custom can deal with the ensuing confusion->a Windows boot option in the GRUB menu that doesn't boot Windows as expected.
If there's not enough will to implement option a) (or some workaround with the same effect), we'll have to change our release criterion (option c) - I'd probably propose some changes to the wording).
I just made it match the OS X criterion (which should be renamed macOS, this section is dating itself :P)
I don't see any benefit in delaying the status quo (option d)). But we should also clarify the situation to our users. On the Fedora download page, we should make it clear that users with an encrypted drive will not be able to boot Windows out of the box anymore, and they'll need to take additional steps to get into Windows.
Yeah, I agree that absent software solutions to the problem, we definitely need better documentation. Fedora download page, and Ask Fedora.
If there's one thing I'd like to communicate, it's *your data is OK!* You've previous reported users became convinced installing Fedora broke Windows, and resulted in data loss. That's how bad the experience is. And it's sad that some folks just gave up and ended up toasting their own data due to this confusion.
The thing I keep coming back to is this is not just bad for Fedora, it's bad for all the distros that support dual boot Windows.
That might include a tool in Fedora (option b)), or figuring out how to get to a one-time boot menu.
I'm not sure how much we can depend on the firmware's built-in boot manager for anything. I'm pretty sure we can depend on the firmware honoring bootnext and bootorder.
Windows can show Fedora as a boot option. shift key+restart -> Use A Device -> Fedora. This sets a bootnext variable in NVRAM for the firmware to follow.
It should also contain instructions on how to switch back to the Windows bootloader by default (after installation, and ideally also as an option during installation), and how to boot Fedora then.
A note: Option b) mentions the Windows boot menu would get removed on UEFI systems - it would be good to do this only if anaconda detects a Bitlocker partition. There's no need to make it harder for Windows users who do not have their disks encrypted.
GRUB isn't that smart. Bitlocker could be enabled by the user at any time, if it's not enabled by default.
My inclination is *if* upstream GRUB Is going to abandon this use case, there might as well be a clean break. Keep it on BIOS, remove it entirely on UEFI.
-- Chris Murphy
Once upon a time, Chris Murphy lists@colorremedies.com said:
This is a good point to underscore. The user experience following a Fedora installation when Bitlocker is enabled, is the appearance of Windows being broken or inaccessible. We are probably better off asking Anaconda to refuse to install when Bitlocker is detected. Or at least a warning dialog.
This brings up something I've wondered about... I have a Thinkpad T14 (gen 2a) bought earlier this year. I shrunk the pre-installed Windows within Windows before installing Fedora 35. I have no real need to access it from Linux (only reason I didn't delete Windows is it's a work computer).
I did poke at it though, and trying to mount it (with no FS type specified) returns "unknown filesystem type 'BitLocker'.". When I boot into Windows, it still works fine (no issue booting). I tried to get a recovery key, but Windows says it's not encrypted.
On Wed, Jul 27, 2022 at 7:15 AM Chris Adams linux@cmadams.net wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
This is a good point to underscore. The user experience following a Fedora installation when Bitlocker is enabled, is the appearance of Windows being broken or inaccessible. We are probably better off asking Anaconda to refuse to install when Bitlocker is detected. Or at least a warning dialog.
This brings up something I've wondered about... I have a Thinkpad T14 (gen 2a) bought earlier this year. I shrunk the pre-installed Windows within Windows before installing Fedora 35. I have no real need to access it from Linux (only reason I didn't delete Windows is it's a work computer).
I did poke at it though, and trying to mount it (with no FS type specified) returns "unknown filesystem type 'BitLocker'.". When I boot into Windows, it still works fine (no issue booting). I tried to get a recovery key, but Windows says it's not encrypted.
My understanding is that Windows preloads are now blank-encrypted. That is, there's a BitLocker volume wrapping the filesystem, even with encryption turned off. It makes encrypting the disk later significantly easier (it doesn't have to do filesystem resizing and reallocation games).
Once upon a time, Neal Gompa ngompa13@gmail.com said:
My understanding is that Windows preloads are now blank-encrypted. That is, there's a BitLocker volume wrapping the filesystem, even with encryption turned off. It makes encrypting the disk later significantly easier (it doesn't have to do filesystem resizing and reallocation games).
Huh, okay. It seems cryptsetup can't open it, but dislocker can.
But this does mean that doing anything in anaconda based on detection of BitLocker being present should consider that...
On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
Once upon a time, Neal Gompa ngompa13@gmail.com said:
My understanding is that Windows preloads are now blank-encrypted. That is, there's a BitLocker volume wrapping the filesystem, even with encryption turned off. It makes encrypting the disk later significantly easier (it doesn't have to do filesystem resizing and reallocation games).
Huh, okay. It seems cryptsetup can't open it, but dislocker can.
You can do something like
dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C
And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I wouldn't be surprised if it's encrypted, and the encryption key itself isn't wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can discover and cryptsetup can't (yet) - but I'm speculating.
But this does mean that doing anything in anaconda based on detection of BitLocker being present should consider that...
Either libblkid or cryptsetup would need to learn how to differentiate between the two kinds of Bitlocker volumes, in order for anaconda to have a chance of treating them differently. I'm not sure what the consideration would be though.
On 27/07/2022 17:52, Chris Murphy wrote:
On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
Once upon a time, Neal Gompa ngompa13@gmail.com said:
My understanding is that Windows preloads are now blank-encrypted. That is, there's a BitLocker volume wrapping the filesystem, even with encryption turned off. It makes encrypting the disk later significantly easier (it doesn't have to do filesystem resizing and reallocation games).
Huh, okay. It seems cryptsetup can't open it, but dislocker can.
You can do something like
dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C
And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I wouldn't be surprised if it's encrypted, and the encryption key itself isn't wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can discover and cryptsetup can't (yet) - but I'm speculating.
But this does mean that doing anything in anaconda based on detection of BitLocker being present should consider that...
Either libblkid or cryptsetup would need to learn how to differentiate between the two kinds of Bitlocker volumes, in order for anaconda to have a chance of treating them differently. I'm not sure what the consideration would be though.
If you report this as a bug for cryptsetup (with description how to create such Bitlocker volume), we can check how to fix it.
Otherwise nothing happens :-)
The libblkid change will be perhaps simple once we understand metadata.
Milan
On Wed, Jul 27, 2022, at 1:17 PM, Milan Broz wrote:
On 27/07/2022 17:52, Chris Murphy wrote:
On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
Once upon a time, Neal Gompa ngompa13@gmail.com said:
My understanding is that Windows preloads are now blank-encrypted. That is, there's a BitLocker volume wrapping the filesystem, even with encryption turned off. It makes encrypting the disk later significantly easier (it doesn't have to do filesystem resizing and reallocation games).
Huh, okay. It seems cryptsetup can't open it, but dislocker can.
You can do something like
dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C
And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I wouldn't be surprised if it's encrypted, and the encryption key itself isn't wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can discover and cryptsetup can't (yet) - but I'm speculating.
But this does mean that doing anything in anaconda based on detection of BitLocker being present should consider that...
Either libblkid or cryptsetup would need to learn how to differentiate between the two kinds of Bitlocker volumes, in order for anaconda to have a chance of treating them differently. I'm not sure what the consideration would be though.
If you report this as a bug for cryptsetup (with description how to create such Bitlocker volume), we can check how to fix it.
Otherwise nothing happens :-)
Yeah that's what I meant by "(yet)" :D
On Wed, Jul 27, 2022 at 5:53 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
Once upon a time, Neal Gompa ngompa13@gmail.com said:
My understanding is that Windows preloads are now blank-encrypted. That is, there's a BitLocker volume wrapping the filesystem, even with encryption turned off. It makes encrypting the disk later significantly easier (it doesn't have to do filesystem resizing and reallocation games).
Huh, okay. It seems cryptsetup can't open it, but dislocker can.
You can do something like
dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C
And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I wouldn't be surprised if it's encrypted, and the encryption key itself isn't wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can discover and cryptsetup can't (yet) - but I'm speculating.
This is also what happens if you choose to "decrypt" your BitLocker volume in Windows so if it is this case, cryptsetup doesn't support it. We intentionally ignored this case mostly because it looked like a small corner case (if you choose do decrypt the volume, Windows will in the end fully decrypt the data and get rid of the BitLocker volume/container), but if it's going to be a widespread use, we might need to start looking into that. As Milan said, a reproducer and an upstream issue for cryptsetup would be nice.
But this does mean that doing anything in anaconda based on detection of BitLocker being present should consider that...
Either libblkid or cryptsetup would need to learn how to differentiate between the two kinds of Bitlocker volumes, in order for anaconda to have a chance of treating them differently. I'm not sure what the consideration would be though.
If it really is the case described above, from libblkid point of view, this is still BitLocker and the data is still encrypted so no difference in how it should be handled -- mount cannot mount it, ntfsresize cannot resize it so for all intents and purposes it is a BitLocker volume and we cannot treat it differently just because the volume key itself is not protected.
-- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Jul 28, 2022, at 2:11 AM, Vojtech Trefny wrote:
On Wed, Jul 27, 2022 at 5:53 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
Once upon a time, Neal Gompa ngompa13@gmail.com said:
My understanding is that Windows preloads are now blank-encrypted. That is, there's a BitLocker volume wrapping the filesystem, even with encryption turned off. It makes encrypting the disk later significantly easier (it doesn't have to do filesystem resizing and reallocation games).
Huh, okay. It seems cryptsetup can't open it, but dislocker can.
You can do something like
dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C
And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I wouldn't be surprised if it's encrypted, and the encryption key itself isn't wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can discover and cryptsetup can't (yet) - but I'm speculating.
This is also what happens if you choose to "decrypt" your BitLocker volume in Windows so if it is this case, cryptsetup doesn't support it. We intentionally ignored this case mostly because it looked like a small corner case (if you choose do decrypt the volume, Windows will in the end fully decrypt the data and get rid of the BitLocker volume/container), but if it's going to be a widespread use, we might need to start looking into that. As Milan said, a reproducer and an upstream issue for cryptsetup would be nice.
But this does mean that doing anything in anaconda based on detection of BitLocker being present should consider that...
Either libblkid or cryptsetup would need to learn how to differentiate between the two kinds of Bitlocker volumes, in order for anaconda to have a chance of treating them differently. I'm not sure what the consideration would be though.
If it really is the case described above, from libblkid point of view, this is still BitLocker and the data is still encrypted so no difference in how it should be handled -- mount cannot mount it, ntfsresize cannot resize it so for all intents and purposes it is a BitLocker volume and we cannot treat it differently just because the volume key itself is not protected.
I think one of the thread responders was thinking that it would be possible to still use a GRUB menu entry for the decrypted BitLocker case.
Once upon a time, Vojtech Trefny vtrefny@redhat.com said:
This is also what happens if you choose to "decrypt" your BitLocker volume in Windows so if it is this case, cryptsetup doesn't support it. We intentionally ignored this case mostly because it looked like a small corner case (if you choose do decrypt the volume, Windows will in the end fully decrypt the data and get rid of the BitLocker volume/container), but if it's going to be a widespread use, we might need to start looking into that. As Milan said, a reproducer and an upstream issue for cryptsetup would be nice.
Unfortunately, I don't know a reproducer, other than "buy a Thinkpad". I don't actually know much about Windows stuff.
On Thu, Jul 28, 2022 at 2:39 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Vojtech Trefny vtrefny@redhat.com said:
This is also what happens if you choose to "decrypt" your BitLocker volume in Windows so if it is this case, cryptsetup doesn't support it. We intentionally ignored this case mostly because it looked like a small corner case (if you choose do decrypt the volume, Windows will in the end fully decrypt the data and get rid of the BitLocker volume/container), but if it's going to be a widespread use, we might need to start looking into that. As Milan said, a reproducer and an upstream issue for cryptsetup would be nice.
Unfortunately, I don't know a reproducer, other than "buy a Thinkpad". I don't actually know much about Windows stuff.
Ok, I found there is some OEM BitLocker configuration that sounds like it might be it:
"BitLocker automatic device encryption starts during Out-of-box (OOBE) experience. However, protection is enabled (armed) only after users sign in with a Microsoft Account or an Azure Active Directory account. Until that, protection is suspended and data is not protected." https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/...
I'll try to find more and try to figure out how OEM installation works with Windows and see if we can add support for this case to cryptsetup.
-- Chris Adams linux@cmadams.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Once upon a time, Vojtech Trefny vtrefny@redhat.com said:
"BitLocker automatic device encryption starts during Out-of-box (OOBE) experience. However, protection is enabled (armed) only after users sign in with a Microsoft Account or an Azure Active Directory account. Until that, protection is suspended and data is not protected." https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/...
I'll try to find more and try to figure out how OEM installation works with Windows and see if we can add support for this case to cryptsetup.
That sounds like what I did - I specificallly avoided making a Microsoft account to sign in (it's Windows Pro, so I went through initial config with no network connected/configured).
On Wed, Jul 27, 2022 at 12:12 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 26/07/2022 20:05, Chris Murphy wrote:
Thoughts?
e. Switch from GRUB 2 to systemd-boot for the UEFI installations.
Making it easier to choose to install systemd-boot rather than grub (including signing systemd-boot) at install would seem be a good first step along that path since grub upstream has made their position clear. So if using systemd-boot ends up being a requirement for (reasonably easy) dual booting recent Fedora and Windows, I would be OK with that (and while there are ways to get recent Windows installed without TPM or UEFI, that hoop jumping is sufficiently complicated that you are not going to expect many to do so, and one then cannot easily take advantage of the built in disk encryption).
On 26/07/2022 20:05, Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result:
Microsoft has published a new security bulletin on the current state of Secure Boot: https://docs.microsoft.com/en-us/windows/security/information-protection/sec...
The most important note:
Secured-core PCs require Secure Boot to be enabled and configured to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide customers with the most secure configuration of their PCs possible.
TL;DR. The new certified by Microsoft devices will be able to load only Microsoft Windows in the UEFI Secure Boot enabled mode.
"Microsoft <3 Linux", "Microsoft is a friend", "Microsoft has changed", - they said.
* Vitaly Zaitsev via devel:
On 26/07/2022 20:05, Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result:
Microsoft has published a new security bulletin on the current state of Secure Boot: https://docs.microsoft.com/en-us/windows/security/information-protection/sec...
The most important note:
Secured-core PCs require Secure Boot to be enabled and configured to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide customers with the most secure configuration of their PCs possible.
TL;DR. The new certified by Microsoft devices will be able to load only Microsoft Windows in the UEFI Secure Boot enabled mode.
"Microsoft <3 Linux", "Microsoft is a friend", "Microsoft has changed", - they said.
But they also say this:
| The default state of Secure Boot has a wide circle of trust which can | result in customers trusting boot components they may not need. Since | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA | signature in the UEFI database increase[]s the attack surface of | systems. A customer who intended to only trust and boot a single Linux | distribution will trust all distributions–much more than their desired | configuration.
And this is an accurate description of the situation.
Unfortunately, Fedora promoted this broken model with pervasive cross-distribution/cross-OS trust as well. People are generally quick to criticize those who control a PKI, but very few organizations are willing to step up to hold the key material for the key of last resort because of the risk inherent to that. Consequently, pretty much all distributions hide behind the Microsoft key, instead of running their own PKI and working with OEMs to get it accepted by the firmware.
I wonder if this Secure Boot interoperability failure is the result of using PKI in a situation where it is really not applicable. Based on a shim/first-stage boot loader, Microsoft cannot really tell what it will boot eventually, and no meaningful security review is possible. It doesn't help that Microsoft does not embed the name of the party who submitted an UEFI driver for signing in the signature itself. (If Microsoft is able to authenticate driver authors properly, this would allow the firmware to provide an informative prompt for unknown boot loaders.)
Maybe the answer to that this issue is to have a minimal (cross-distribution) boot loader that displays the SHA-256 hash of second-stage boot loaders (requiring physical presence before booting), and offer to to enrol their hashes for future automated boots (similar to SSH's leap-of-faith authentication). The second stage boot loader can have a long-term distribution-specific key embedded in it and is also supposed to be minimal, so that distribution upgrades do not require re-enrollment of the per-distribution boot loader.
I doubt it will be acceptable to Linux distributions, though. People taught Linux to extract public keys from signed UEFI binaries in an attempt to avoid runnig their own PKI. And if Microsoft drastically cuts back signing services (because the new model doesn't need Microsoft signatures anymore), they would no longer be able to offload which Linux kernel module authors to trust to Microsoft.
Thanks, Florian
On Fri, Jul 29, 2022 at 11:26:15AM +0200, Florian Weimer wrote:
- Vitaly Zaitsev via devel:
On 26/07/2022 20:05, Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result:
Microsoft has published a new security bulletin on the current state of Secure Boot: https://docs.microsoft.com/en-us/windows/security/information-protection/sec...
The most important note:
Secured-core PCs require Secure Boot to be enabled and configured to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide customers with the most secure configuration of their PCs possible.
TL;DR. The new certified by Microsoft devices will be able to load only Microsoft Windows in the UEFI Secure Boot enabled mode.
"Microsoft <3 Linux", "Microsoft is a friend", "Microsoft has changed", - they said.
But they also say this:
| The default state of Secure Boot has a wide circle of trust which can | result in customers trusting boot components they may not need. Since | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA | signature in the UEFI database increase[]s the attack surface of | systems. A customer who intended to only trust and boot a single Linux | distribution will trust all distributions–much more than their desired | configuration.
And this is an accurate description of the situation.
Unfortunately, Fedora promoted this broken model with pervasive cross-distribution/cross-OS trust as well. People are generally quick to criticize those who control a PKI, but very few organizations are willing to step up to hold the key material for the key of last resort because of the risk inherent to that. Consequently, pretty much all distributions hide behind the Microsoft key, instead of running their own PKI and working with OEMs to get it accepted by the firmware.
Would the situation actually be any different in that case ? Assume an alternate reality where hardware OEMs magically agreed to pre-install 20 different keys for the various Linux vendors.
You still have the same "problem" that you're running 1 specific vendor's OS, but your firmware trusts the software from countless different unrelated vendors for SecureBoot.
Either way though, IIUC, this ought not to be a problem if combining SecureBoot with TPM measurements. The firmware measures the SecureBoot signing key of the OS binary that is booted into PCR 7.
So if BitLocker keys are tied to PCR-7 when it was booted with the Microsoft Windows UEFI CA, then any attempt to boot an OS signed by the Microsoft 3rd Party UEFI CA would get different PCR-7 measurements and so BitLocker keys are safe.
On the Linux side, IIUC shim will measure the certificate that signed the Linux OS it loads into PCR-7 too. So if the Linux guest ties LUKS keys to PCR-7, then again it should be secure[1] against someone trying to boot a different Linux vendor's OS.
With regards, Daniel
[1] I'm ignoring the inconvenient initrd hole that exists in more or less all Linux OS wrt boot measurements. That's a technical impl flaw, rather than an inherant problem of the SecureBoot/TPM techology.
* Daniel P. Berrangé:
Unfortunately, Fedora promoted this broken model with pervasive cross-distribution/cross-OS trust as well. People are generally quick to criticize those who control a PKI, but very few organizations are willing to step up to hold the key material for the key of last resort because of the risk inherent to that. Consequently, pretty much all distributions hide behind the Microsoft key, instead of running their own PKI and working with OEMs to get it accepted by the firmware.
Would the situation actually be any different in that case ? Assume an alternate reality where hardware OEMs magically agreed to pre-install 20 different keys for the various Linux vendors.
You still have the same "problem" that you're running 1 specific vendor's OS, but your firmware trusts the software from countless different unrelated vendors for SecureBoot.
No, in this model, if you buy a Fedora server, it only boots Fedora until manual intervention. I don't think this is a problem because Secure Boot with that very open signing policy is not very far from disabled Secure Boot.
Either way though, IIUC, this ought not to be a problem if combining SecureBoot with TPM measurements. The firmware measures the SecureBoot signing key of the OS binary that is booted into PCR 7.
So if BitLocker keys are tied to PCR-7 when it was booted with the Microsoft Windows UEFI CA, then any attempt to boot an OS signed by the Microsoft 3rd Party UEFI CA would get different PCR-7 measurements and so BitLocker keys are safe.
If Microsoft is confident that their boot path has physical presence checks before destructive operations, they can enable booting from media (even the network by default). That can be used to add powerful recovery tools for their users.
Right now, that's risky because pretty much all Linux distributions allow you to create an initrd that wipes all storage media. It's also more likely that you can run code before certain Secure Boot milestones have been rached during the boot process. (And of course it's also possible to impersonate the Windows login screen and log the user's password this.) As far as I understand it, Microsoft has locked down the early boot process to a significant degree (even extending to userspace), so these types of attacks are less likely to be successful in a Windows-only environment. Locking out other bootloaders by default as a defense-in-depth measure doesn't seem so far-fetched to me.
Honestly, I had expected this to happen far sooner, and only over time assumed that it would probably never happen for some non-security reasons.
Thanks, Florian
On Fri, Jul 29, 2022 at 01:52:28PM +0200, Florian Weimer wrote:
- Daniel P. Berrangé:
Unfortunately, Fedora promoted this broken model with pervasive cross-distribution/cross-OS trust as well. People are generally quick to criticize those who control a PKI, but very few organizations are willing to step up to hold the key material for the key of last resort because of the risk inherent to that. Consequently, pretty much all distributions hide behind the Microsoft key, instead of running their own PKI and working with OEMs to get it accepted by the firmware.
Would the situation actually be any different in that case ? Assume an alternate reality where hardware OEMs magically agreed to pre-install 20 different keys for the various Linux vendors.
You still have the same "problem" that you're running 1 specific vendor's OS, but your firmware trusts the software from countless different unrelated vendors for SecureBoot.
No, in this model, if you buy a Fedora server, it only boots Fedora until manual intervention. I don't think this is a problem because Secure Boot with that very open signing policy is not very far from disabled Secure Boot.
Ah, so you mean getting the OEMs to preload the Linux OS distro of choice, not merely preloading a distro's SecureBoot keys.
With regards, Daniel
- Vitaly Zaitsev via devel:
But they also say this:
| The default state of Secure Boot has a wide circle of trust which can | result in customers trusting boot components they may not need. Since | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA | signature in the UEFI database increase[]s the attack surface of | systems. A customer who intended to only trust and boot a single Linux | distribution will trust all distributions–much more than their desired | configuration.
And this is an accurate description of the situation.
Unfortunately, Fedora promoted this broken model with pervasive cross-distribution/cross-OS trust as well. People are generally quick to criticize those who control a PKI, but very few organizations are willing to step up to hold the key material for the key of last resort because of the risk inherent to that. Consequently, pretty much all distributions hide behind the Microsoft key, instead of running their own PKI and working with OEMs to get it accepted by the firmware.
I mean there are hundreds of distributions, and hundreds if not thousands of OEM. How could that even work? _maybe_ major OEMs would pick up the phone if it's Redhat, Canonical and maybe SUSE who are calling. What about everyone else?
Florian Weimer wrote:
But they also say this:
| The default state of Secure Boot has a wide circle of trust which can | result in customers trusting boot components they may not need. Since | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA | signature in the UEFI database increase[]s the attack surface of | systems. A customer who intended to only trust and boot a single Linux | distribution will trust all distributions–much more than their desired | configuration.
And this is an accurate description of the situation.
Unfortunately, Fedora promoted this broken model with pervasive cross-distribution/cross-OS trust as well.
And what is the alternative? The whole model of allowing to boot only a whitelist of operating systems is inherently a vendor lock-in and hence inherently broken. Restricting the list to one or two (Microsoft and [distro of choice]) vendors out of the box is totally anticompetitive and a freedom killer.
People are generally quick to criticize those who control a PKI, but very few organizations are willing to step up to hold the key material for the key of last resort because of the risk inherent to that. Consequently, pretty much all distributions hide behind the Microsoft key, instead of running their own PKI and working with OEMs to get it accepted by the firmware.
Nonsense. OEMs have made it pretty clear from day one that they will not trust any other company than Microsoft out of the box. That, and nothing else, is why everyone is forced to rely on Microsoft's key.
Microsoft's third-party key was from the beginning an alibi action to avoid monopoly lawsuits and boycotts. (I guess the processing fee of, IIRC, $100, was not the main motivator, they would probably charge more if that were the case. So that fee only stands as a barrier to exclude smaller GNU/Linux distributions.) They would not have been able to pull off Restricted Boot with so little upcry without that alibi key. I can only assume that they were, from day one, only waiting for a good excuse to pull the plug on that key, and it seems that the excuse has now been found. If they were serious about equal access to hardware for all manufacturers, they would have used the SAME signing-key as for their own operating systems.
I wonder if this Secure Boot interoperability failure is the result of using PKI in a situation where it is really not applicable.
Well, indeed, PKI is not applicable to the boot process at all, because the whole idea of not booting all operating systems out of the box is anticompetitive, anti-freedom, and flawed.
Maybe the answer to that this issue is to have a minimal (cross-distribution) boot loader that displays the SHA-256 hash of second-stage boot loaders (requiring physical presence before booting), and offer to to enrol their hashes for future automated boots (similar to SSH's leap-of-faith authentication).
Requiring users to jump through even more hoops to boot their operating system of choice is not going to be acceptable to anybody.
The only answer I see is that Restricted Boot needs to go away. But that is why Microsoft is now abusing full-disk encryption to make it impossible to disable Restricted Boot without destroying all your data. (Chainloading is not the only way to change the TPM measurements and hence break the TPM sealing, disabling Restricted Boot will also do it.)
It makes me particularly sad when I see GNU/Linux developers touting the purported security merits of Restricted Boot and TPM Treacherous Computing in their blogs.
Kevin Kofler
It doesn't help that Microsoft does not embed the name of the party
who submitted an UEFI driver for signing in the signature itself.
Microsoft does do this; it's in an authenticated attribute with OID 1.3.6.1.4.1.311.2.1.12, aka "SPC_SP_OPUS_INFO_OBJID", it's documented as part of Office document file formats (VBA signing): https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-oshared/91...
The same thing is done for Windows drivers that they sign; Windows understands this attribute (binaries from specific parties can be blocked by the CiPolicy/SiPolicy which is Microsoft's current Windows-specific revocation list du jour), but UEFI firmware does not (yet).
Hi,
But they also say this:
| The default state of Secure Boot has a wide circle of trust which can | result in customers trusting boot components they may not need. Since | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA | signature in the UEFI database increase[]s the attack surface of | systems. A customer who intended to only trust and boot a single Linux | distribution will trust all distributions–much more than their desired | configuration.
And this is an accurate description of the situation.
Yea. And on top of that there is no standard way to manage secure boot keys. Try to kick out the microsoft windows signing keys because you don't trust the windows boot loader and want use linux anyway.
You can go into the efi setup and with luck you find options to manage keys.
But some standard way for a OS to request that and the firmware asking the user on next boot to ack or nack that action is just not there. Same for adding linux distro keys. This is why we ended up with shim + mokutil in the first place ...
The second stage boot loader can have a long-term distribution-specific key embedded in it and is also supposed to be minimal, so that distribution upgrades do not require re-enrollment of the per-distribution boot loader.
I'd love to have the distro CA cert on iso images and ESP, preferably in some standard location. Then people have at least the chance to easily enroll the distro keys (assuming the firmware setup offers that). For virtual machines we could even do that automatically.
RHEL can actually be be booted with only distro keys enrolled, even though it requires inconvenient manual configuration due to having two shim.efi binaries with one signature each instead of one binary with two signatures.
Fedora secure boot signing is rather messy though. Booting without microsoft cert doesn't work: https://bugzilla.redhat.com/show_bug.cgi?id=2108083
And the fedora distro secure boot certificate is broken: https://bugzilla.redhat.com/show_bug.cgi?id=2107982
take care, Gerd
On Thu, Jul 28, 2022 at 07:47:15PM +0200, Vitaly Zaitsev via devel wrote:
On 26/07/2022 20:05, Chris Murphy wrote:
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result:
Microsoft has published a new security bulletin on the current state of Secure Boot: https://docs.microsoft.com/en-us/windows/security/information-protection/sec...
The most important note:
Secured-core PCs require Secure Boot to be enabled and configured to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide customers with the most secure configuration of their PCs possible.
TL;DR. The new certified by Microsoft devices will be able to load only Microsoft Windows in the UEFI Secure Boot enabled mode.
I read that as meaning there are two different certifications
* "Certified For Windows PCs" - the traditional behaviour we've known, where the 3rd party UEFI CA is enabled by defualt
* "Secured-core PCs" - a new certification promoted as a more secure out of the box setup, where 3rd party UEFI CA is disabled by default
This doesn't mean that everything is suddenly going to be 'Secure-cored" and thus prevent use of shim out of the box.
This other doc gives more details
https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/...
[quote] Microsoft works closely with OEM partners to help ensure that all certified Windows systems deliver a secure operating environment. Windows integrates closely with the hardware to deliver protections that take advantage of available hardware capabilities:
* Baseline Windows security – recommended baseline for all individual systems that provides foundational system integrity protections. Leverages TPM 2.0 for a hardware root of trust, secure boot and BitLocker drive encryption. * Virtualization-based security enabled – leverages virtualization capabilities from hardware and the hypervisor to provide additional protection for critical subsystems and data. * Secured-core – recommended for the most sensitive systems and industries like financial, healthcare, and government agencies. Builds on the previous layers and leverages advanced processor capabilities to provide protection from firmware attacks. [/quote]
An open question is just how widely the OEM hardware vendors will deploy "Secured core" hardware in practice. If they only do this for enterprise hardware they sell with Windows pre-installed, then it might not become a big deal, as those running Linux will typically opt out of Windows pre-install. If they deploy 'Secured core' across all hardware, both consumer and enterprise, and/or regardless of OS preinstall choice, then it will become more of a pain for consumers wanting to run Linux.
With regards, Daniel
On 29/07/2022 11:55, Daniel P. Berrangé wrote:
This doesn't mean that everything is suddenly going to be 'Secure-cored" and thus prevent use of shim out of the box.
They will begin enforcing this "Secure-cored" policy very soon.
An open question is just how widely the OEM hardware vendors will deploy "Secured core" hardware in practice.
Lenovo has already started: https://www.phoronix.com/news/Lenovo-Pluton-Windows-Default
Hi,
haven't read all the posts, maybe this was mentioned in one of them.
What about an EFI binary, which sets the next boot entry and initiates a reboot? This can be loaded by grub with the next boot device as parameter, which can be dynamically set on grub config generation. Or even as a BLS entry.
Kind regards Philipp
On Fri, Jul 29, 2022, at 9:29 AM, Philipp Homann wrote:
Hi,
haven't read all the posts, maybe this was mentioned in one of them.
What about an EFI binary, which sets the next boot entry and initiates a reboot? This can be loaded by grub with the next boot device as parameter, which can be dynamically set on grub config generation. Or even as a BLS entry.
I guess GRUB could chainload this EFI program. The EFI program looks for the "Windows" boot entry in NVRAM and sets it as bootnext, then reboots the system.
Of course this EFI binary would need to be signed with an appropriate Fedora CA for UEFI Secure Boot.
I don't know if making this a standlone EFI program really accelerates getting it ready to deploy, compared to just making it a GRUB module.
On Tue, 26 Jul 2022 at 19:06, Chris Murphy lists@colorremedies.com wrote:
b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader.
In fwupd we add a BootXXXX target and sets BootNext to run the capsule update loader. 99.99% of the time it works just fine, ~0.01% of the time it corrupts all the other BootXXXX entries, including the default windows one. We support chainloading from grub for exactly this reason....
Richard
-
Barry -
Chris Adams -
Chris Murphy -
Christian Brauner -
Daniel P. Berrangé -
Demi Marie Obenour -
Florian Weimer -
Gary Buhrmaster -
Gerd Hoffmann -
Gregory Bartholomew -
Hieu Ha -
Javier Martinez Canillas -
Kamil Paral -
Kevin Kofler -
Lennart Poettering -
Luca Boccassi -
Luya Tshimbalanga -
Milan Broz -
Neal Gompa -
Nico Kadel-Garcia -
Peter Boy -
Petr Pisar -
Philipp Homann -
Richard Hughes -
Stephen Smoogen -
Tomasz Torcz -
Vitaly Zaitsev -
Vojtech Trefny -
Zammis Clark