1:05 p.m.
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_d...
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
3:06 p.m.
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
3:11 p.m.
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.
--
Chris Murphy
3:37 p.m.
On Tue, Jul 26, 2022 at 1:12 PM Chris Murphy <lists(a)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!
3:42 p.m.
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
3:59 p.m.
On Tue, Jul 26, 2022 at 1:43 PM Kevin Kofler via devel
<devel(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
6:14 p.m.
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.
--
Chris Murphy
6:18 p.m.
Once upon a time, Chris Murphy <lists(a)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?
--
Chris Adams <linux(a)cmadams.net>
6:24 p.m.
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(a)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`
--
Chris Murphy
8:15 p.m.
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
8:41 p.m.
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
8:56 p.m.
On Tue, Jul 26, 2022, at 7:18 PM, Chris Adams wrote:
Once upon a time, Chris Murphy <lists(a)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?
--
Chris Murphy
9:34 p.m.
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.
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
10:07 p.m.
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/...
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
1:10 a.m.
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.
--
Tomasz Torcz “(…) today's high-end is tomorrow's embedded processor.”
tomek(a)pipebreaker.pl — Mitchell Blank on LKML
3:42 a.m.
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:
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_d...
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:55 a.m.
On Tue, Jul 26, 2022 at 8:06 PM Chris Murphy <lists(a)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_d...
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?
8:55 a.m.
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
9:13 a.m.
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...
--
Chris Murphy
9:14 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
Once upon a time, Chris Murphy <lists(a)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.
--
Chris Adams <linux(a)cmadams.net>
9:17 a.m.
On Wed, Jul 27, 2022 at 12:12 PM Vitaly Zaitsev via devel
<devel(a)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).
9:31 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Wed, Jul 27, 2022 at 7:15 AM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Chris Murphy <lists(a)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).
--
真実はいつも一つ！/ Always, there's only one truth!
10:11 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora,
redux)
Once upon a time, Neal Gompa <ngompa13(a)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...
--
Chris Adams <linux(a)cmadams.net>
10:52 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
Once upon a time, Neal Gompa <ngompa13(a)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.
--
Chris Murphy
11:11 a.m.
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:53 a.m.
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.
--
Chris Murphy
12:17 p.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora,
redux)
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(a)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
12:25 p.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
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(a)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
--
Chris Murphy
1:36 p.m.
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
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3:19 p.m.
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.
--
Chris Murphy
3:27 p.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3:30 p.m.
On Mi, 27.07.22 10:13, Chris Murphy (lists(a)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:
https://efi.akeo.ie/
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
3:47 p.m.
On Mi, 27.07.22 16:19, Chris Murphy (lists(a)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
3:50 p.m.
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.
--
Chris Murphy
4:01 p.m.
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.o...
--
Chris Murphy
4:04 p.m.
On Mi, 27.07.22 16:50, Chris Murphy (lists(a)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
4:07 p.m.
On Mi, 27.07.22 17:01, Chris Murphy (lists(a)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
4:15 p.m.
On Wed, Jul 27, 2022, at 4:47 PM, Lennart Poettering wrote:
On Mi, 27.07.22 16:19, Chris Murphy (lists(a)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.
--
Chris Murphy
4:28 p.m.
On Wed, Jul 27, 2022 at 10:31 PM Lennart Poettering
<mzerqung(a)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
4:35 p.m.
On Wed, Jul 27, 2022, at 5:07 PM, Lennart Poettering wrote:
On Mi, 27.07.22 17:01, Chris Murphy (lists(a)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.
--
Chris Murphy
4:45 p.m.
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(a)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?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
4:46 p.m.
On Wed, Jul 27, 2022 at 17:37 Chris Murphy <lists(a)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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
5:47 p.m.
On Mi, 27.07.22 17:15, Chris Murphy (lists(a)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(a)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
5:50 p.m.
On Mi, 27.07.22 17:35, Chris Murphy (lists(a)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
10:01 p.m.
On Wed, Jul 27, 2022, at 9:46 PM, Stephen Smoogen wrote:
On Wed, Jul 27, 2022 at 17:37 Chris Murphy <lists(a)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(a)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
1:11 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Wed, Jul 27, 2022 at 5:53 PM Chris Murphy <lists(a)colorremedies.com> wrote:
On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
> Once upon a time, Neal Gompa <ngompa13(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
7:11 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Thu, Jul 28, 2022, at 2:11 AM, Vojtech Trefny wrote:
On Wed, Jul 27, 2022 at 5:53 PM Chris Murphy
<lists(a)colorremedies.com> wrote:
>
>
>
> On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote:
> > Once upon a time, Neal Gompa <ngompa13(a)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.
--
Chris Murphy
7:38 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora,
redux)
Once upon a time, Vojtech Trefny <vtrefny(a)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.
--
Chris Adams <linux(a)cmadams.net>
8:24 a.m.
On Di, 26.07.22 13:37, Neal Gompa (ngompa13(a)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
8:31 a.m.
On Wed, Jul 27, 2022 at 2:05 PM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mi, 27.07.22 16:50, Chris Murphy (lists(a)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.
This sounds pretty awesome, actually. I'd like to see that get implemented...
--
真実はいつも一つ！/ Always, there's only one truth!
9:54 a.m.
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(a)0pointer.de> wrote:
>
> On Mi, 27.07.22 16:50, Chris Murphy (lists(a)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.
>
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
10:11 a.m.
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-s...
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/...
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.
10:25 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)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.
--
Chris Adams <linux(a)cmadams.net>
10:40 a.m.
On Do, 28.07.22 16:54, Petr Pisar (ppisar(a)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
10:43 a.m.
On Do, 28.07.22 10:25, Chris Adams (linux(a)cmadams.net) wrote:
Once upon a time, Lennart Poettering <mzerqung(a)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
11:52 a.m.
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
12:47 p.m.
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/...
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:05 p.m.
On Thu, Jul 28, 2022 at 10:40 AM Lennart Poettering <mzerqung(a)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/141...
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.
1:33 p.m.
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/141... 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
1:47 p.m.
On Thu, Jul 28, 2022 at 1:34 PM Chris Murphy <lists(a)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?
2:03 p.m.
On Thu, Jul 28, 2022, at 2:47 PM, Gregory Bartholomew wrote:
On Thu, Jul 28, 2022 at 1:34 PM Chris Murphy
<lists(a)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
3:14 p.m.
On Do, 28.07.22 13:05, Gregory Bartholomew (gregory.lee.bartholomew(a)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/141...
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
3:17 p.m.
On Do, 28.07.22 15:03, Chris Murphy (lists(a)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
5:18 p.m.
On Thu, Jul 28, 2022 at 3:17 PM Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
On Do, 28.07.22 15:03, Chris Murphy (lists(a)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. :)
5:21 p.m.
Am 28.07.2022 um 22:17 schrieb Lennart Poettering
<mzerqung(a)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.
12:52 a.m.
On Tue, Jul 26, 2022 at 4:07 PM Kevin Kofler via devel
<devel(a)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?
12:58 a.m.
On Tue, Jul 26, 2022 at 9:16 PM Kevin Kofler via devel
<devel(a)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.
2:22 a.m.
On 29 Jul 2022, at 06:53, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
On Tue, Jul 26, 2022 at 4:07 PM Kevin Kofler via devel
<devel(a)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?
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
3:38 a.m.
On Thu, Jul 28, 2022 at 6:52 PM Chris Murphy <lists(a)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-ca...
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).
4:25 a.m.
On Fr, 29.07.22 00:21, Peter Boy (pboy(a)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
4:26 a.m.
* 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/...
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
4:55 a.m.
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/...
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-experienc...
[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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
5:08 a.m.
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/...
>
> 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.
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
6:46 a.m.
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
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:52 a.m.
* 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
7:05 a.m.
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:31 a.m.
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-ca...
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
8:02 a.m.
On Fri, Jul 29, 2022, at 5:25 AM, Lennart Poettering wrote:
On Fr, 29.07.22 00:21, Peter Boy (pboy(a)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.
--
Chris Murphy
8:29 a.m.
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
8:46 a.m.
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.
--
Chris Murphy
9:02 a.m.
On Do, 28.07.22 17:18, Gregory Bartholomew (gregory.lee.bartholomew(a)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
9:38 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Thu, Jul 28, 2022 at 2:39 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Vojtech Trefny <vtrefny(a)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-experienc...
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(a)cmadams.net>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
9:47 a.m.
* 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?
10:09 a.m.
New subject: BitLocker (was Re: future of dual booting Windows and Fedora,
redux)
Once upon a time, Vojtech Trefny <vtrefny(a)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-experienc...
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).
--
Chris Adams <linux(a)cmadams.net>
10:16 a.m.
On Tue, 26 Jul 2022 at 19:06, Chris Murphy <lists(a)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
11:03 a.m.
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
11:20 a.m.
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
4:31 a.m.
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...
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).
5:51 a.m.
On Fri, Jul 29, 2022 at 2:32 PM Chris Murphy <lists(a)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-ca...
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.
8:10 a.m.
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
9:32 a.m.
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
619
days inactive
640
days old
92 comments
28 participants
participants (28)
-
Barry -
Chris Adams -
Chris Murphy -
Christian Brauner -
Daniel P. Berrangé -
Demi Marie Obenour -
Florian Weimer -
Gary Buhrmaster -
Gerd Hoffmann -
Gregory Bartholomew -
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