subject:"F38 proposal\: Unified Kernel Support Phase 1 \(System\-Wide Change proposal\)"

On Mon, Jan 02, 2023 at 04:06:29PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote:
> [...]
> > Note that uefi http boot can also work with iso images, i.e. you can
> > have the dhcp server hand out URLs to the fedora netboot iso.  The
> > firmware will fetch the iso, create a ramdisk, add a acpi table for
> > it so the OS finds it too, then go boot as it would be a physical
> > cdrom all the way up to anaconda.
> 
> That sounds very interesting. Could you describe how to set this up
> and/or provide some links to documentation?

On uefi http boot:

https://www.redhat.com/sysadmin/uefi-http-boot-libvirt

To boot iso images you essentially have to just replace
http://server/path/binary.efi with
http://server/path/netboot.iso

HTH & take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

UEFI HTTP boot (was: Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal))

2023-01-02 Thread Dominik 'Rathann' Mierzejewski

On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote:
[...]
> Note that uefi http boot can also work with iso images, i.e. you can
> have the dhcp server hand out URLs to the fedora netboot iso.  The
> firmware will fetch the iso, create a ramdisk, add a acpi table for
> it so the OS finds it too, then go boot as it would be a physical
> cdrom all the way up to anaconda.

That sounds very interesting. Could you describe how to set this up
and/or provide some links to documentation?

Regards,
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> Hi all,
> 
> > == Benefit to Fedora ==
> > * Better secure boot support (specifically the initrd is covered by
> > the signature).
> > * Better confidential computing support (measurements are much more
> > useful if we know what hashes to expect for the initrd).
> > * More robust boot process (generating the initrd on the installed
> > system is fragile, root cause for kernel bugs reported is simply a
> > broken initrd sometimes).
> Just want to add Anaconda installation environment is also fighting with the
> second point.

Third point I assume, i.e. initrd generation problems being reported as
anaconda bugs?

While being at it: anaconda seems to explicitly call dracut to generate
the initrd (according to the messages it prints).  What is the reason
for this?  Shouldn't this already happen as part of the rpm transaction,
when the kernel install scripts are running?

> Thanks to the PXE boot it's maybe even more fragile
> environment.

Yep.  I'd highly recommend to use uefi http boot whenever possible.

Note that uefi http boot can also work with iso images, i.e. you can
have the dhcp server hand out URLs to the fedora netboot iso.  The
firmware will fetch the iso, create a ramdisk, add a acpi table for
it so the OS finds it too, then go boot as it would be a physical
cdrom all the way up to anaconda.

BTW: Having some way other than the kernel command line to pass config
options to anaconda would make this much more useful.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Fri, Dec 23, 2022 at 09:01:52AM +0100, Vitaly Zaitsev via devel wrote:

> I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode
> and vice versa.

Needs installing the signing keys to the shim key database using
mokutil, but should otherwise work just fine.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

  Hi,

> A much better approach is to install a TPM-generated key in the TPM’s
> NVRAM, with a policy that only allows the key to be used once a trusted
> operating system has booted.  That can be used as a trust anchor even
> without support from buggy UEFI firmware.

Side note: measuring kernel + initrd happens using UEFI firmware services.

(once the kernel is up'n'running it will use its own tpm drivers instead
of depending on the firmware services).

> Furthermore, measured boot allows tying e.g. LUKS keys to a
> combination of the actual OS booted and a passphrase needed to unlock
> the TPM.  This allows the TPM’s protection against brute-force attacks
> to be used.

You also want protect the initrd against modifications to make sure an
attacker can't sniff your passphrase.  Unified kernels help here too
because the initrd for a given kernel has a fixed and known hash.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-27 Thread Björn Persson

Lennart Poettering wrote:
> dracut uses fixed offsets for the sections to be placed in memory
> in. The values are simply hardcoded, literally specified address
> offsets, that worked for the original authors. This typically works –
> as long as your sections are not much larger than they were for the
> people wo came up with these offsets initially. But as it turns out
> this doesn't work for some cases. In such cases the sections will be
> loaded into memory overlapped and bad things happen.

Oh yuck! And the manpage is written as if dracut --uefi is expected to
work reliably. I see no big eye-catching warning that such-and-such
must be smaller than x bytes.

Björn Persson


pgpHBtrq05hJe.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-24 Thread Luca Boccassi

> On 12/22/22 15:39, Lennart Poettering wrote:
> 
> 
> 
> Well, the thing with a chain of trust is the fact that the only chain 
> the user can trust is the one that he himself or the host device he owns 
> and operates generated that trust of chain, from link 0 in that chain. ( 
> And we all know how browsers handle self signed certificates who are no 
> less secure than those issued )
> 
> If the user does not generate or otherwise have control over *all* the 
> links in the trust chain, that chain cant be considered trusted now can 
> it, which in turn begs the question why partake in this industry 
> security theater which may brick or otherwise make the end users life 
> more miserable or even exclude certain types of devices, if in the end 
> of the day, the host or the end user is not  "secure" for it.
> 
> Are those efforts truly for the end user or just to meet some 
> industry/government requirements ( some governments require backdoor 
> entrance(s) from vendors for "lawful inspection", backdoor(s) that might 
> be implement or otherwise supported in the trust chain itself if the 
> host or user has not full control over that chain ).

For the vast, vast, vast majority of users a chain of trust that anchors to the 
device manufacturer is more than enough, and solves real-world problems with 
rootkits and such things. End users have to trust the hardware vendors anyway.

For the tiny minority of use cases where that is not enough (and I'm pretty 
sure nobody here is actually interesting enough to fall into that group) 
rolling your own PK is always possible.

Seriously, this "debate" is no longer a debate, it's been done and dusted in 
the 15 years or so secure boot has been a thing, it's been over for a long 
while and it's really time to stop rehashing tired and debunked nonsense. We 
have more important things to do.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-24 Thread Jóhann B . Guðmundsson


On 12/22/22 15:39, Lennart Poettering wrote:


Well, the thing is: a chain of trust is a*chain*, hence you must
ultimately hook validation to what the firmware provides you with as
root. And that ultimately is the SecureBoot db on commodity hardware.



Well, the thing with a chain of trust is the fact that the only chain 
the user can trust is the one that he himself or the host device he owns 
and operates generated that trust of chain, from link 0 in that chain. ( 
And we all know how browsers handle self signed certificates who are no 
less secure than those issued )


If the user does not generate or otherwise have control over *all* the 
links in the trust chain, that chain cant be considered trusted now can 
it, which in turn begs the question why partake in this industry 
security theater which may brick or otherwise make the end users life 
more miserable or even exclude certain types of devices, if in the end 
of the day, the host or the end user is not  "secure" for it.


Are those efforts truly for the end user or just to meet some 
industry/government requirements ( some governments require backdoor 
entrance(s) from vendors for "lawful inspection", backdoor(s) that might 
be implement or otherwise supported in the trust chain itself if the 
host or user has not full control over that chain ).



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Lennart Poettering

On Do, 22.12.22 11:00, Neal Gompa (ngomp...@gmail.com) wrote:

> > OK, so what's left is exactly one issue you had: you tried to enroll 3
> > UEFI certs via mokutil and what exactly happened then? machine
> > bricked how precisely?
>
> The UEFI environment failed to import without reporting failure and
> the system failed to boot, showing garbage instead.

By "uefi environment" you mean shim? Sounds like something to report
to the shim project then.

> > link for a bug report?
>
> Sorry, I can't.

That makes it very hard to do anything about this. To fix a situation
one needs actionable reports.

> No one helped anyway, even back when I could provide more information.
> They're even less likely now that I can't provide that information.

You do realise that you are are complaining but not giving anyone the
chance to do anything about your complaints.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Lennart Poettering

On Fr, 23.12.22 08:51, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> On 22/12/2022 21:29, Chris Murphy wrote:
> > This is a rare but real problem.
>
> I don't think so. Power outage is a very common problem in some countries.
>
> I still remember how unreliable FAT32 was in the Windows 9x era. You needed
> to run a scandisk check after every power failure or pressing the reset
> button. And sometimes your documents or other files disappeared. I really
> don't want a repeat of this.

Nobody is proposing to run the full Linux OS from FAT. I mean, yeah,
in /var and /home people usually do complex write patterns, and the
files there basically are pinned all the time thus cannot be unmounted
during runtime to ensure the file system stays clean most of the time.

But this is different for XBOOTLDR: the autofs logic in systemd
ensures it remains unmounted almost all of the time, and is only very
briefly mounted whenever something actually accesses it. And the write
patterns on XBOOTLDR are comparatively simple: drop in whole file,
erase whole file, plus single-sector writes for some corner cases.

This is *massively* different from the write patterns Windows 9x did
on its file systems.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Lennart Poettering

On Fr, 23.12.22 09:01, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> On 22/12/2022 21:18, Chris Murphy wrote:

> > XBOOTLDR in practice needs to be FAT. I don't like it. But I like
> > it better than choosing batshit as the alternative, and having a
> > bunch of signed efifs drivers on the ESP per distro sounds like
> > batshit to me. And not in the good way.
>
> I don't think so. XBOOTLDR on FAT32 should be rejected as a defective by
> design due to a FAT32 unreliability.

It's not the best file system if you intend to do random access writes
all the time. But if you don't do that, restrict your write patterns
to a certain reasonably safe subset, and ensure that you keep the file
system unmounted most of the time then it should be OK. I mean, UEFI
effectively mandates FAT for one partition (i.e. the ESP), you can't
avoid it. And at the bare minimum the boot loader is stored in the
ESP, and you need to update that as regularly as any other software
package, hence it's illusionary that you could avoid regular write
patterns onto FAT if you just make XBOOTLDR something non-FAT.

> I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode
> and vice versa.

After enrolling the Ubuntu key via mokutil that should be fine. Sure,
if you have the shim belonging to distro X then this means only
kernels of distro X can be just booted, since only X' certificate will
be built-in. But once you enroll other certs things should be fine.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Luca Boccassi

> On Thu, Dec 22, 2022 at 12:42:38PM -0600, Dennis Gilmore wrote:
> Different architectures have different boot loaders. In particular, s390x and
> ppc64el are very different. The proposal is to add support for UKIs in grub2, 
> so
> that we will cover UEFI and non-UEFI machines that use grub2. For other
> architectures, we can in principle do the same thing… After all, the UKI is 
> just
> a binary with a few sections appended. But it seems to early to think such
> details far ahead. As extensively discussed, the support for separate initrds 
> is
> not going anyway and the proposal only targets a small subset of the amd64 
> space.

Also, doesn't u-boot support those architectures? The latest u-boot UEFI 
interface seems to work quite well when I tried, including support for secure 
boot.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Luca Boccassi

> On 22/12/2022 21:29, Chris Murphy wrote:
> 
> I don't think so. Power outage is a very common problem in some countries.
> 
> I still remember how unreliable FAT32 was in the Windows 9x era. You 
> needed to run a scandisk check after every power failure or pressing the 
> reset button. And sometimes your documents or other files disappeared. I 
> really don't want a repeat of this.

As mentioned many times already, vfat here is not used to keep files open for 
continuous editing or things like that, where that experience might be 
repeated. It's single-block or as-atomic-as-it-can-be single-file swap (and 
with newer kernels it looks like there's actual atomic rename too). So "files 
disappearing" due to power outages are extremely unlikely in this particular 
use case. The worst case scenario is that you end up with both old-and-new 
UKIs, which means you can still boot (and there's no "valuable" data to be lost 
here, everything that goes in the ESP can be regenerated on the next boot). On 
the other hand reimplementing filesystem drivers in the bootloader can result 
in broken filesystems or worse, security vulnerabilities. This is something 
that actually happens and keeps happening.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Luca Boccassi

> On 12/22/22 12:00, Luca Boccassi wrote:
> 
> As Neal mentioned earlier, these mechanisms are often broken.  Not only
> does some firmware wind up bricking the machine when they are used, they
> also may not support removing the key used to sign Windows.  If the
> attacker can boot Windows and measured boot is not in use, they have won.

Nah, it's the other way around. Linux is severely behind Windows, and I mean 
really severely.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Jóhann B . Guðmundsson


On 12/20/22 21:27, Simo Sorce wrote:


Finally, unless this proposal harms Fedora I do not see why oppose it.
If, as you fear, it won't work ... then it won't and we'll try
something else.



You do realize that the day that Lenovo started to sell it's hardware 
with Fedora pre-installed ( as it was convinced to do) , the days of 
Fedora doing somekind of experiments on it's users base to see what 
sticks or making decisions like hey people if this does not work let's 
try something else, were over right? ( atleast for the workstation 
working group ).



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Dec 22, 2022 at 12:42:38PM -0600, Dennis Gilmore wrote:
> On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > > In my case, I have Network Manager config files included in my initrd
> > > and bootargs to bring up the network so that I get automatic disk
> > > decryption while on my home network, and prompted for a password when
> > > I am not at home. I think this a reasonable enough use case it should
> > > be considered in the long term plan. There was an effort many years
> > > ago that built the initramfs with the kernel, it was abandoned due to
> > > not being able to guarantee sources for the binaries in the initramfs,
> >
> > If a UKI is built in koji, the initrd it embeds must also be built in koji. 
> > And
> > when the initrd is built in koji, it is just taking some binaries from rpms 
> > and
> > repacking them. We ensure that we have an srpm for any official srpm. Thus, 
> > going
> > back from the UKI, you look up the initrd, and the logs for the initrd 
> > build,
> > and get a list of rpms, and then look the appropriate srpms from that, and 
> > from
> > the srpms you get the sources. There's a few more steps, but the 
> > availability of
> > sources is guaranteed using the mechanism existing for normal rpms.
> 
> In the past that was deemed to not be good enough. by legal as it is
> too hard for the average user to do.

Sorry, but that doesn't make any sense.

Quoting Daniel Berrange from the other part of the thread:
> This is the same situation we already have in Fedora with
> libguestfs, where we're building a disk image inside Koji bundling
> various binaries. Or for that matter, not really different from
> building cloud disk images, or any other deliverable that bundles
> together some binaries from other RPMs and spits out some kind of
> image or archive.

My understanding is that if any of those other things (including any
of our installation media that also contain an kernel and programs in
the initrd) are fine, UKIs must be fine too.

> > > trying to dig up the details I am having trouble finding it, but legal
> > > blocked it there is a reference to it in an old FESCo meeting
> > > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> > > Additionally, we should also consider
> > > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > > implications and why we moved to have kernel-core, kernel-modules, and
> > > kernel-modules-extra for cloud and different use cases.
> >
> > Yes. That's why this proposal explicitly targets a narrow use case which 
> > doesn't
> > need many drivers and will support many different machines with the same
> > (relatively small) initrd.
> 
> I think the proposal needs to be explicit in how other use cases and
> all architectures will be handled. I think if we do not have a path
> for all architectures to be supported we should spend more time
> working out how to cover them all.

Different architectures have different boot loaders. In particular, s390x and
ppc64el are very different. The proposal is to add support for UKIs in grub2, so
that we will cover UEFI and non-UEFI machines that use grub2. For other
architectures, we can in principle do the same thing… After all, the UKI is just
a binary with a few sections appended. But it seems to early to think such
details far ahead. As extensively discussed, the support for separate initrds is
not going anyway and the proposal only targets a small subset of the amd64 
space.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-23 Thread Vitaly Zaitsev via devel

On 22/12/2022 21:18, Chris Murphy wrote:

XBOOTLDR in practice needs to be FAT. I don't like it. But I like it better
than choosing batshit as the alternative, and having a bunch of signed efifs
drivers on the ESP per distro sounds like batshit to me. And not in the good
way.

I don't think so. XBOOTLDR on FAT32 should be rejected as a defective by
design due to a FAT32 unreliability.

It's harder to fix this problem if XBOOTLDR is not FAT. efifs drivers need to be Secure Boot signed just like the bootloader. The firmware already trusts its built-in FAT driver, for better or worse, so what is the exact problem with just using that so we don't have to deal with UEFI SB signing efifs drivers, and the much harder job of expecting every distro to include signed efifs drivers *on the ESP* for multiboot to work?

Who we are to make decisions for other Linux distributions? Every
distribution can use whatever they want.

I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot
mode and vice versa.

--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Vitaly Zaitsev via devel


On 22/12/2022 21:29, Chris Murphy wrote:

This is a rare but real problem.


I don't think so. Power outage is a very common problem in some countries.

I still remember how unreliable FAT32 was in the Windows 9x era. You 
needed to run a scandisk check after every power failure or pressing the 
reset button. And sometimes your documents or other files disappeared. I 
really don't want a repeat of this.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Demi Marie Obenour

On 12/22/22 12:00, Luca Boccassi wrote:
>> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
>> >
>> Basically, I'm saying that the model of trust is flawed because users
>> are unable to work with it.
>>
>> And besides, each level up is a smaller scope from the previous. A
>> cert trusted by shim can execute anything the firmware trusts, a cert
>> trusted by grub can only execute things it trusts, and finally a cert
>> trusted by the OS can only execute things in its context. Once we
>> reach the OS-level, we don't need pre-boot trust anymore. So enrolling
>> certificates to trust kernel modules/sysexts/etc. should not require
>> going down the trust levels. The OS should be able to establish its
>> own trust to those pieces or reject them independently. It should
>> certainly trust everything the lower levels trust, but there's no
>> reason to not allow the higher levels to establish their own scoped
>> trust.
>>
>> This is the flaw we have right now: we can't do that.
> 
> Of course there's a reason to only allow a fully validated trust chain - not 
> only that, but it's the very basic of the entire model, and without it the 
> entire premise falls flat on its face.
> The way to enroll your own certs is via firmware-mediated mechanisms such as 
> shim+mok, and via built-in trusted keyring. Adding arbitrary trust anchors at 
> the OS level completely ignores the foundational principle of the whole thing.

As Neal mentioned earlier, these mechanisms are often broken.  Not only
does some firmware wind up bricking the machine when they are used, they
also may not support removing the key used to sign Windows.  If the
attacker can boot Windows and measured boot is not in use, they have won.

A much better approach is to install a TPM-generated key in the TPM’s
NVRAM, with a policy that only allows the key to be used once a trusted
operating system has booted.  That can be used as a trust anchor even
without support from buggy UEFI firmware.  Furthermore, measured boot
allows tying e.g. LUKS keys to a combination of the actual OS booted and
a passphrase needed to unlock the TPM.  This allows the TPM’s protection
against brute-force attacks to be used.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Demi Marie Obenour

On 12/22/22 12:33, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi  wrote:
>>
>>> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
>>> >>
>>> Basically, I'm saying that the model of trust is flawed because users
>>> are unable to work with it.
>>>
>>> And besides, each level up is a smaller scope from the previous. A
>>> cert trusted by shim can execute anything the firmware trusts, a cert
>>> trusted by grub can only execute things it trusts, and finally a cert
>>> trusted by the OS can only execute things in its context. Once we
>>> reach the OS-level, we don't need pre-boot trust anymore. So enrolling
>>> certificates to trust kernel modules/sysexts/etc. should not require
>>> going down the trust levels. The OS should be able to establish its
>>> own trust to those pieces or reject them independently. It should
>>> certainly trust everything the lower levels trust, but there's no
>>> reason to not allow the higher levels to establish their own scoped
>>> trust.
>>>
>>> This is the flaw we have right now: we can't do that.
>>
>> Of course there's a reason to only allow a fully validated trust chain -
>> not only that, but it's the very basic of the entire model, and without
>> it the entire premise falls flat on its face.  The way to enroll your own
>> certs is via firmware-mediated mechanisms such as shim+mok, and via
>> built-in trusted keyring. Adding arbitrary trust anchors at the OS level
>> completely ignores the foundational principle of the whole thing.
> 
> Your concept only works in *some* enterprise hardware where it's even
> possible to have full control without breaking something. Even in my
> server gear, I can't do that without breaking the network firmware.

What???  That is strange.

> If I can't safely distrust Microsoft reliably, then it's already broken.

Absolutely.  Otherwise, an attacker can just boot into Windows and
use any of the numerous bring-your-own-vulnerable-driver exploits to
get code execution in the kernel.  To stop this, one needs to remove
the Microsoft signing key from the root store.

> Firmware trust has been broken since the very beginning, and it was
> broken by design in the PC world.
> 
> Consumer PC equipment is even worse off because of how Microsoft's
> Windows requirements influence how UEFI implementations work.

IMO a much more realistic approach for bare hardware is measured boot,
using Dynamic Root of Trust for Measurement (DRTM) where available.
The latter is the basis of Qubes OS’s Anti Evil Maid.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Chris Murphy



On Wed, Dec 21, 2022, at 12:00 PM, Lennart Poettering wrote:
> On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
>
>> For the general case we need some other option.  Could be just stick to
>> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
>> and ppc64le).  Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers,
>> for example this one:
>>   https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg
>
> I am pretty strongly against the idea of ext4 for /boot/.
>
> First of all, the firmware can't read it natively, but what's worse,
> uefi cannot even make sense of any of the features it provides above
> vfat. i.e. file ownership, access modes, ACLs, selinux labels, xattrs,
> symlinks, … are all complete nonsense to the UEFI fs layer (and to
> boot loaders that natively implement the fs drivers, the same). The
> UEFI fs API has no concepts for *any* of these features. Hence, if
> this is supposed to carry data intended for consumption by the boot
> loader, why the f**k would you use a file system it cannot even
> remotely take benefit of?

And for btrfs, the GRUB btrfs.mod doesn't do any checksum checking at all, so 
there's not even an incremental improvement to integrity, let alone any support 
for fs-verity. So while I like btrfs for /boot due to the space efficiency 
advantage (I don't have to ask how big boot should be, no space is wasted and I 
don't run out either), I'm willing to give it up for practical matters like 
simplicity and reduced attack and maintenance surface area.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Chris Murphy

On Wed, Dec 21, 2022, at 6:53 AM, Vitaly Zaitsev via devel wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
>> Why shouldn't FAT be used for /boot.  In an EFI world, /boot
>> is used for the same functional pupose as the ESP, which is
>> already going to use FAT.
>
> Doesn't support links, lournaling and ACLs.

What's the use case? Is it a nice to have or is it a hard requirement and why?

The Linux FAT driver does support SELinux context with a mount option. We 
aren't using that right now but we can have a suitable SELinux label enforced 
file system wide on ESP and XBOOTLDR.

> Everyone can do whatever they want with the files, and a trivial power 
> outage can easily wipe out all of its contents.

This is a rare but real problem. I think we should be looking at ESP and 
XBOOTLDR updates doing A/B updates, i.e. write the updates to temporary files 
or directories and then use renameat(2) which is atomic at the VFS layer, and 
should get pretty close to atomic at the FAT layer to the degree that worse 
case scenario we have either the old *and* new files following a crash. Ideally 
we'd get old *or* new. But that's probably not possible with FAT. But we can 
still boot. 

>> Such drivers would need to be signed to be used
>> under SecureBoot, thus expanding the set of components you
>> need to audit & trust for security purposes.
>
> These drivers are backports from the grub2 code. If we trust GRUB, we 
> can trust them too.
>
> Fedora Infra can be configured to sign the contents of the efifs package 
> with a Fedora SB key.

Yeah but then try getting all the distros to agree on signing efifs. How many 
distros are there? It's not unfair to say  all distros should be able to put 
their signed efifs drivers on the ESP because that's the only way their 
bootloader can read loader/entries to properly draw a boot menu.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Chris Murphy

On Wed, Dec 21, 2022, at 6:22 AM, Vitaly Zaitsev via devel wrote:
> On 20/12/2022 19:56, Chris Murphy wrote:
>> Great. The gotcha though is this in effect requires a change in the file 
>> system currently mounted at /boot, which is ext4. And ext4 isn't supported 
>> by sd-boot or UEFI firmware. So if you're going to support sd-boot, the 
>> installer needs to be aware that either the ESP is big enough to be used as 
>> /boot, or if it's not big enough then it will be mounted on /efi*and*  a new 
>> partition XBOOTLDR formatted as FAT will be used as /boot.
>
> Nobody should use FAT for /boot. efifs[1] should be used instead.
>
> systemd-boot can load these drivers from ESP out of the box[2].

The founding principle in Boot Loader Spec is that multiboot between Linux 
distros sucks. The cooperation between distros, is shit. And BLS strives to 
present an opportunity to compromise and fix that problem.

It's harder to fix this problem if XBOOTLDR is not FAT. efifs drivers need to 
be Secure Boot signed just like the bootloader. The firmware already trusts its 
built-in FAT driver, for better or worse, so what is the exact problem with 
just using that so we don't have to deal with UEFI SB signing efifs drivers, 
and the much harder job of expecting every distro to include signed efifs 
drivers *on the ESP* for multiboot to work? 

If /boot is ext4, then every Linux distro must include a signed ext4 efifs 
driver in order to properly render the boot menu. But what if (open)SUSE 
doesn't want to use ext4, they want Btrfs? Compromise dictates that every 
distro now needs to provide a signed btrfs efifs driver too. OK Red Hat uses 
XFS for boot, so now every distro needs to include ext4, btrfs, and XFS signed 
efifs drivers with every installation. It's explosively more complicated to 
implement let alone to agree upon than just use the one driver we know everyone 
has and can use.

XBOOTLDR in practice needs to be FAT. I don't like it. But I like it better 
than choosing batshit as the alternative, and having a bunch of signed efifs 
drivers on the ESP per distro sounds like batshit to me. And not in the good 
way.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Dennis Gilmore via devel

On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > In my case, I have Network Manager config files included in my initrd
> > and bootargs to bring up the network so that I get automatic disk
> > decryption while on my home network, and prompted for a password when
> > I am not at home. I think this a reasonable enough use case it should
> > be considered in the long term plan. There was an effort many years
> > ago that built the initramfs with the kernel, it was abandoned due to
> > not being able to guarantee sources for the binaries in the initramfs,
>
> If a UKI is built in koji, the initrd it embeds must also be built in koji. 
> And
> when the initrd is built in koji, it is just taking some binaries from rpms 
> and
> repacking them. We ensure that we have an srpm for any official srpm. Thus, 
> going
> back from the UKI, you look up the initrd, and the logs for the initrd build,
> and get a list of rpms, and then look the appropriate srpms from that, and 
> from
> the srpms you get the sources. There's a few more steps, but the availability 
> of
> sources is guaranteed using the mechanism existing for normal rpms.

In the past that was deemed to not be good enough. by legal as it is
too hard for the average user to do.

> > trying to dig up the details I am having trouble finding it, but legal
> > blocked it there is a reference to it in an old FESCo meeting
> > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> > Additionally, we should also consider
> > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > implications and why we moved to have kernel-core, kernel-modules, and
> > kernel-modules-extra for cloud and different use cases.
>
> Yes. That's why this proposal explicitly targets a narrow use case which 
> doesn't
> need many drivers and will support many different machines with the same
> (relatively small) initrd.

I think the proposal needs to be explicit in how other use cases and
all architectures will be handled. I think if we do not have a path
for all architectures to be supported we should spend more time
working out how to cover them all.

> Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Luca Boccassi

> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi  
> Your concept only works in *some* enterprise hardware where it's even
> possible to have full control without breaking something. Even in my
> server gear, I can't do that without breaking the network firmware. If
> I can't safely distrust Microsoft reliably, then it's already broken.
> 
> Firmware trust has been broken since the very beginning, and it was
> broken by design in the PC world.

"My" (not really mine, but whatever) concept works on pretty much every single 
x86 consumer device sold in the past ~12 years, in every public cloud provider, 
a gazillion arm64 use cases, and more. It's only "broken" if by that you mean 
that an entire class of very real and very much alive in the wild malware 
infections are no longer possible.
Of course if you do things like deleting the 3rd party UEFI CA on machines that 
require option roms to work without allow-listing or re-signing, then things 
break, but that has absolutely nothing to do with the "concept" - if you delete 
a trust anchor, objects trusted by it are no longer trusted in the absence of 
an alternative chain, that's pretty much expected behaviour.
Obviously things can always be improved, and we are working on that, SBAT is 
the first step in that direction. But saying that the trust chain model is 
broken is simply untrue.

> Consumer PC equipment is even worse off because of how Microsoft's
> Windows requirements influence how UEFI implementations work.

You meant to say "light years ahead" here - it is not even funny anymore how 
far behind Linux is to Windows w.r.t. security, especially in the boot process. 
We have been playing catch-up for 10 years and are nowhere near done. It is 
very fortunate for the ecosystem at large that there are people who actually 
understand the threat models pushing the industry forward, because if it was up 
to the hardware vendors computer security would still be where it was in the 
mid 90s.

But we are working on it, and making progress - in some technical concepts we 
are even ahead of them right now (eg: signed TPM policies, FIDO2 for luks, 
Windows doesn't have anything like that), but only in PoCs. Now we need the 
wide adoption, and this proposal is one timid step forward in that direction. 
The fact that in 2022 there is still no mainstream distro that has closed the 
glaring security gaping hole of writable, untrusted initrd (yes some distros 
have non-default specialized flavours for this, but it's niche) should be a 
source of embarrassment for anybody who works on OS development. It is a 
difficult problem, but by no means impossible, and it really ought to have been 
fixed at least for the generic use case by now. We need to get this sorted at 
long last.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi  wrote:
>
> > On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
> >  >
> > Basically, I'm saying that the model of trust is flawed because users
> > are unable to work with it.
> >
> > And besides, each level up is a smaller scope from the previous. A
> > cert trusted by shim can execute anything the firmware trusts, a cert
> > trusted by grub can only execute things it trusts, and finally a cert
> > trusted by the OS can only execute things in its context. Once we
> > reach the OS-level, we don't need pre-boot trust anymore. So enrolling
> > certificates to trust kernel modules/sysexts/etc. should not require
> > going down the trust levels. The OS should be able to establish its
> > own trust to those pieces or reject them independently. It should
> > certainly trust everything the lower levels trust, but there's no
> > reason to not allow the higher levels to establish their own scoped
> > trust.
> >
> > This is the flaw we have right now: we can't do that.
>
> Of course there's a reason to only allow a fully validated trust chain - not 
> only that, but it's the very basic of the entire model, and without it the 
> entire premise falls flat on its face.
> The way to enroll your own certs is via firmware-mediated mechanisms such as 
> shim+mok, and via built-in trusted keyring. Adding arbitrary trust anchors at 
> the OS level completely ignores the foundational principle of the whole thing.

Your concept only works in *some* enterprise hardware where it's even
possible to have full control without breaking something. Even in my
server gear, I can't do that without breaking the network firmware. If
I can't safely distrust Microsoft reliably, then it's already broken.

Firmware trust has been broken since the very beginning, and it was
broken by design in the PC world.

Consumer PC equipment is even worse off because of how Microsoft's
Windows requirements influence how UEFI implementations work.



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 02:49:37PM +, Daniel P. Berrangé wrote:
> > There are at three ways that are used: 'dracut --uefi', systemd's ukify, 
> > and a
> > manual objcopy invocation. The first two are wrappers around objcopy. I'm 
> > biased
> > because I wrote 'ukify', but I think that's the way to go. What dracut does 
> > is
> > somewhat primitive and doesn't get the offsets right. Obviously it could be
> > improved, but putting the code to generate UKIs inside of an initrd 
> > generator is
> > a historical accident, and bash is not the nicest language to do offset
> > calculations. Thus I hope we can standarize on ukify instead.
> 
> When you say it dooesn't get the offsets right, can you elaborate ?
> We've been using dracut --uefi to build the UKIs in koji and they
> appear to work as expected. Are the offsets only incorrect in
> certain circumstances.

When the kernel binary happens to be too big things break because the
end of the kernel will overlap with the start of the initrd due to the
fixed offsets used and thus the fixes space being available for the
kernel binary (and the other things being added to the uki, except
initrd which comes last).

Which is not the case right now with fedora kernels, so everything works
fine.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:52:05AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering
>  wrote:
> >
> > BTW, you keep talking of "these" problems, and are extremely vague
> > about those. I think I understood that you hit the NVRAM size limits
> > before, by enrolling private certs?
> 
> Yes.

Physical hardware or virtual machines?

For virtual machines:  Fedora uses for historical reasons 2M builds of
OVMF, which have not much NVRAM space.  Alternative 4M builds which have
much more space are available in /usr/share/edk2/ovmf-4m.  Using these
needs manual work right now, hashing out a plan to use these by default
for new VMs without changing/breaking existing VMs is not (yet) done.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Luca Boccassi

> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
>  
> Basically, I'm saying that the model of trust is flawed because users
> are unable to work with it.
> 
> And besides, each level up is a smaller scope from the previous. A
> cert trusted by shim can execute anything the firmware trusts, a cert
> trusted by grub can only execute things it trusts, and finally a cert
> trusted by the OS can only execute things in its context. Once we
> reach the OS-level, we don't need pre-boot trust anymore. So enrolling
> certificates to trust kernel modules/sysexts/etc. should not require
> going down the trust levels. The OS should be able to establish its
> own trust to those pieces or reject them independently. It should
> certainly trust everything the lower levels trust, but there's no
> reason to not allow the higher levels to establish their own scoped
> trust.
> 
> This is the flaw we have right now: we can't do that.

Of course there's a reason to only allow a fully validated trust chain - not 
only that, but it's the very basic of the entire model, and without it the 
entire premise falls flat on its face.
The way to enroll your own certs is via firmware-mediated mechanisms such as 
shim+mok, and via built-in trusted keyring. Adding arbitrary trust anchors at 
the OS level completely ignores the foundational principle of the whole thing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Dec 22, 2022 at 04:24:11PM +0100, Lennart Poettering wrote:
> On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote:
>
> > When you say it dooesn't get the offsets right, can you elaborate ?
>
> dracut uses fixed offsets for the sections to be placed in memory
> in. The values are simply hardcoded, literally specified address
> offsets, that worked for the original authors. This typically works –
> as long as your sections are not much larger than they were for the
> people wo came up with these offsets initially. But as it turns out
> this doesn't work for some cases. In such cases the sections will be
> loaded into memory overlapped and bad things happen.
>
> ukify hence calculates the offsets manually (by adding up the section
> sizes so that this cannot happen.

The issue was detected in CI [1]. Some code changes made the .text
section bigger, causing other sections to overlap, causing an actual
failure during boot. But it seems that the problem is more widespread and
we were just being lucky ;(  We're figuring out the details,

See the attached program:
$ dracut --uefi /tmp/initrd 6.0.13-300.fc37.x86_64
$ python info.py /tmp/initrd
...
#   4 .rela 10c8  0001f000  0001f000  00017f40  2**2
  start=126976 end=131272
#   5 .osrel02df  0002  0002  00019140  2**2
  start=131072 end=131807
  vma overlap with previous section: 200 bytes
...

I plan to return to this after the holidays.

Zbyszek

[1] https://github.com/systemd/systemd/pull/23706#issuecomment-1354729112
'''\
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 00013aa0  5000  5000  0370  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .reloc000a  00019000  00019000  00013f70  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data 51a8  0001a000  0001a000  00014170  2**4
  CONTENTS, ALLOC, LOAD, DATA
  3 .dynamic  0100  0002  0002  00019370  2**2
  CONTENTS, ALLOC, LOAD, DATA
  4 .osrel029c  0002  0002  00019570  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rela 14e8  00021000  00021000  00019970  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .dynsym   0018  00023000  00023000  0001af70  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .sbat 00d5  00025980  00025980  0001b170  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .sdmagic  0027  00025a60  00025a60  0001b370  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .cmdline  0032  0003  0003  0001b570  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .linux00c285e8  0200  0200  0001b770  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .initrd   038a76ee  0300  0300  00c43d70  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
'''

import subprocess
import sys
dump = subprocess.check_output(['objdump', '-h', sys.argv[1]], text=True)

prev = None

print(dump)

for line in dump.splitlines()[5::2]:
print(f'# {line}')
idx, name, size, vma, lma, file_off, align = line.split()

idx = int(idx)
size = int(size, 16)
vma = int(vma, 16)
lma = int(lma, 16)
file_off = int(file_off, 16)
align = eval(align)

print(f'  start={vma} end={vma + size}')

if prev:
gap = file_off - prev[5] - prev[2]
if gap < 0:
print(f'  file offset overlap with previous section: {-gap} bytes')

gap = vma - prev[3] - prev[2]
if gap < 0:
print(f'  vma overlap with previous section: {-gap} bytes')

prev = (idx, name, size, vma, lma, file_off, align)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:56 AM Lennart Poettering
 wrote:
>
> On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote:
> 65;6800;1c
> > > BTW, you keep talking of "these" problems, and are extremely vague
> > > about those. I think I understood that you hit the NVRAM size limits
> > > before, by enrolling private certs?
> >
> > Yes. Specifically for dealing with the NVIDIA driver, backports of
> > Intel network card drivers, OpenZFS, ELRepo modules, etc.
> >
> > > What are those issues precisely? Did you file bugs? How many certs did
> > > you try to enroll? Or did you try to enroll hashes? Were was this
> > > dicussed?
> >
> > Anywhere between 1 to 3 UEFI certs, representing different vendors
> > (machine-local, ELRepo, and OpenZFS).
>
> OK, so what's left is exactly one issue you had: you tried to enroll 3
> UEFI certs via mokutil and what exactly happened then? machine
> bricked how precisely?
>

The UEFI environment failed to import without reporting failure and
the system failed to boot, showing garbage instead.

> link for a bug report?
>

Sorry, I can't.

> Please be specific, otherwise noone will be able to help you!
>

No one helped anyway, even back when I could provide more information.
They're even less likely now that I can't provide that information.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
 wrote:
>
> On Do, 22.12.22 10:43, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering
> >  wrote:
> > >
> > > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:
> > >
> > > > > I understand the big issue you have is that the certificate store for
> > > > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > > > NVRAM is limited in size? If that's the big issue you are having then
> > > > > that's absolutely something the Linux community can fix, and can
> > > > > address. Specifically, shim could allow storing the cert store on
> > > > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > > > doable. And certainly not the firmware's fault...
> > > > >
> > > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > > > currently done.
> > > >
> > > > Frankly, I'm aggravated by the increased reliance on UEFI features
> > > > without fixing Linux's problems with UEFI features. If we stopped
> > > > relying on UEFI for the cert store, a lot of my issues would go away,
> > > > because then we can design better workflows for managing
> > > > certificates.
> > >
> > > Well, the thing is: a chain of trust is a *chain*, hence you must
> > > ultimately hook validation to what the firmware provides you with as
> > > root. And that ultimately is the SecureBoot db on commodity hardware.
> > >
> > > If I buy a boring laptop at a store it will come with a UEFI cert
> > > store, and nothing else. Linux cannot really ignore that. If it did,
> > > then you'd not have a trusted boot chain, hence the whole excercsie
> > > would be pointless.
> > >
> >
> > Shim trusts MS and the main distro cert, grub is trusted from there,
> > then the OS trusts those and anything else the admin adds. That's how
> > It should work. Trust chains are sensible as long as they're
> > extensible.
>
> Hmm, that chain is partly backwards? it's the firmware that has to
> trust the msft cert which trusts shim, which trusts the distro cert,
> which trusts grub and the kernel. The thing that comes first
> at boot must trust the next, otherwise we'd have to boot into
> untrusted stuff first, which really misses the point? not grokking
> what you are trying tosay?
>

Basically, I'm saying that the model of trust is flawed because users
are unable to work with it.

And besides, each level up is a smaller scope from the previous. A
cert trusted by shim can execute anything the firmware trusts, a cert
trusted by grub can only execute things it trusts, and finally a cert
trusted by the OS can only execute things in its context. Once we
reach the OS-level, we don't need pre-boot trust anymore. So enrolling
certificates to trust kernel modules/sysexts/etc. should not require
going down the trust levels. The OS should be able to establish its
own trust to those pieces or reject them independently. It should
certainly trust everything the lower levels trust, but there's no
reason to not allow the higher levels to establish their own scoped
trust.

This is the flaw we have right now: we can't do that.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote:
65;6800;1c
> > BTW, you keep talking of "these" problems, and are extremely vague
> > about those. I think I understood that you hit the NVRAM size limits
> > before, by enrolling private certs?
>
> Yes. Specifically for dealing with the NVIDIA driver, backports of
> Intel network card drivers, OpenZFS, ELRepo modules, etc.
>
> > What are those issues precisely? Did you file bugs? How many certs did
> > you try to enroll? Or did you try to enroll hashes? Were was this
> > dicussed?
>
> Anywhere between 1 to 3 UEFI certs, representing different vendors
> (machine-local, ELRepo, and OpenZFS).

OK, so what's left is exactly one issue you had: you tried to enroll 3
UEFI certs via mokutil and what exactly happened then? machine
bricked how precisely?

link for a bug report?

Please be specific, otherwise noone will be able to help you!

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Jiri Konecny


Hi all,

Dne 20. 12. 22 v 16:22 Ben Cotton napsal(a):

https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Add support for unified kernels images to Fedora.



== Feedback ==


== Benefit to Fedora ==
* Better secure boot support (specifically the initrd is covered by
the signature).
* Better confidential computing support (measurements are much more
useful if we know what hashes to expect for the initrd).
* More robust boot process (generating the initrd on the installed
system is fragile, root cause for kernel bugs reported is simply a
broken initrd sometimes).
Just want to add Anaconda installation environment is also fighting with 
the second point. Thanks to the PXE boot it's maybe even more fragile 
environment.
It could be pretty hard to find the root cause because it could fine on 
basically anything (mostly XFS modules).


Best Regards,
Jirka
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering
 wrote:
>
> On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > I have to think about what happens when the cat is out of the bag.
> > What I want is not necessarily a solution to this now, but a
> > commitment that someone will actively work on fixing these problems
> > *before* proposing the next phase and have it ready *before* making
> > any future proposals on UKIs. If you can't do that, I can't in good
> > faith consider incrementally supporting UKIs, because there's
> > effectively no plan to make them work as a future default way of
> > shipping the Linux kernel.
>
> BTW, you keep talking of "these" problems, and are extremely vague
> about those. I think I understood that you hit the NVRAM size limits
> before, by enrolling private certs?
>

Yes. Specifically for dealing with the NVIDIA driver, backports of
Intel network card drivers, OpenZFS, ELRepo modules, etc.

> What are those issues precisely? Did you file bugs? How many certs did
> you try to enroll? Or did you try to enroll hashes? Were was this
> dicussed?
>

Anywhere between 1 to 3 UEFI certs, representing different vendors
(machine-local, ELRepo, and OpenZFS).

> Without any of that the vagueness just constitutes FUD... Hence,
> please be more specific!
>

You know better than that. Stop it.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 10:43, Neal Gompa (ngomp...@gmail.com) wrote:

> On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering
>  wrote:
> >
> > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > > I understand the big issue you have is that the certificate store for
> > > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > > NVRAM is limited in size? If that's the big issue you are having then
> > > > that's absolutely something the Linux community can fix, and can
> > > > address. Specifically, shim could allow storing the cert store on
> > > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > > doable. And certainly not the firmware's fault...
> > > >
> > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > > currently done.
> > >
> > > Frankly, I'm aggravated by the increased reliance on UEFI features
> > > without fixing Linux's problems with UEFI features. If we stopped
> > > relying on UEFI for the cert store, a lot of my issues would go away,
> > > because then we can design better workflows for managing
> > > certificates.
> >
> > Well, the thing is: a chain of trust is a *chain*, hence you must
> > ultimately hook validation to what the firmware provides you with as
> > root. And that ultimately is the SecureBoot db on commodity hardware.
> >
> > If I buy a boring laptop at a store it will come with a UEFI cert
> > store, and nothing else. Linux cannot really ignore that. If it did,
> > then you'd not have a trusted boot chain, hence the whole excercsie
> > would be pointless.
> >
>
> Shim trusts MS and the main distro cert, grub is trusted from there,
> then the OS trusts those and anything else the admin adds. That's how
> It should work. Trust chains are sensible as long as they're
> extensible.

Hmm, that chain is partly backwards? it's the firmware that has to
trust the msft cert which trusts shim, which trusts the distro cert,
which trusts grub and the kernel. The thing that comes first
at boot must trust the next, otherwise we'd have to boot into
untrusted stuff first, which really misses the point? not grokking
what you are trying tosay?

> > > You *need* to think about these problems when designing this stuff.
> > > You can't take a myopic x86-only view to this. I have not heard of
> > > anything about UKI security for non-x86 because it seems to all be
> > > tied up in UEFI stuff.
> >
> > I work for a company that is working on ARM UEFI systems booting UKIs
> > in massive scale.
>
> One company is one company. It's not a variety of people and users.
> Scale means nothing if it's not distributed.

Well, you said you have not "heard" of anyone doing UKI security on
non-x86. Now you have.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote:

> I have to think about what happens when the cat is out of the bag.
> What I want is not necessarily a solution to this now, but a
> commitment that someone will actively work on fixing these problems
> *before* proposing the next phase and have it ready *before* making
> any future proposals on UKIs. If you can't do that, I can't in good
> faith consider incrementally supporting UKIs, because there's
> effectively no plan to make them work as a future default way of
> shipping the Linux kernel.

BTW, you keep talking of "these" problems, and are extremely vague
about those. I think I understood that you hit the NVRAM size limits
before, by enrolling private certs?

What are those issues precisely? Did you file bugs? How many certs did
you try to enroll? Or did you try to enroll hashes? Were was this
dicussed?

Without any of that the vagueness just constitutes FUD... Hence,
please be more specific!

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering
 wrote:
>
> On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > I understand the big issue you have is that the certificate store for
> > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > NVRAM is limited in size? If that's the big issue you are having then
> > > that's absolutely something the Linux community can fix, and can
> > > address. Specifically, shim could allow storing the cert store on
> > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > doable. And certainly not the firmware's fault...
> > >
> > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > currently done.
> >
> > Frankly, I'm aggravated by the increased reliance on UEFI features
> > without fixing Linux's problems with UEFI features. If we stopped
> > relying on UEFI for the cert store, a lot of my issues would go away,
> > because then we can design better workflows for managing
> > certificates.
>
> Well, the thing is: a chain of trust is a *chain*, hence you must
> ultimately hook validation to what the firmware provides you with as
> root. And that ultimately is the SecureBoot db on commodity hardware.
>
> If I buy a boring laptop at a store it will come with a UEFI cert
> store, and nothing else. Linux cannot really ignore that. If it did,
> then you'd not have a trusted boot chain, hence the whole excercsie
> would be pointless.
>

Shim trusts MS and the main distro cert, grub is trusted from there,
then the OS trusts those and anything else the admin adds. That's how
It should work. Trust chains are sensible as long as they're extensible.

In a perfect world, they would work properly at the lowest levels, but
between commercial and community malpractice, they don't.

> > It makes automation possible, it makes management possible, and it
> > opens the doors to experiment with how to do layered images for boot
> > (e.g. UKIs + system extension images) without bricking people's
> > computers.
>
> As mentioned before: note that the Fedora signing keys are only built
> into shim and the kernel, not stored in NVRAM.
>
> But anyway, I think it would be great if shim could manage a cert
> store on disk, I already said that. But that's truly orthogonal to
> UKIs and sysext really. You keep trying to change topics away from
> UKI/sysext towards your general discontent with UEFI.
>
> > That also has the side effect of us having half a chance of being able
> > to port this security capability to non-UEFI platforms where we use
> > fake UEFI implementations to bootstrap our boot process, because the
> > amount of coverage required for fake UEFI implementations is
> > considerably lower now.
> >
> > More generally, relying on UEFI-specific security features when most
> > platforms are not being brought up with UEFI is foolish. ARM is almost
> > entirely non-UEFI (except the tiny proportion of servers that almost
> > no one has) and RISC-V is not a UEFI platform either. POWER uses
> > OpenFirmware instead of UEFI, and IBM Z does something else entirely
> > different.
>
> Well, "foolish", eyh?
>
> The thing is that chain of trust works quite differently on each such
> system (if it exists at all). UEFI is a standardizing and unifying
> force that simplifies things greatly, since while not universal it's
> still the most widely adopted mechanism (and one of the more
> advanced).
>
> Generally, I am very sure we should focus on making the more limited
> stuff work like the modern stuff, and not the other way round. For
> example, there has already been work on making UKIs boot on grub/MBR,
> as mentioned, which is exactly how I think it should be done: move the
> old/legacy/simple stuff work more like the
> new/modern/featureful/standardized stuff, rather than the other way
> round.
>
> > You *need* to think about these problems when designing this stuff.
> > You can't take a myopic x86-only view to this. I have not heard of
> > anything about UKI security for non-x86 because it seems to all be
> > tied up in UEFI stuff.
>
> I work for a company that is working on ARM UEFI systems booting UKIs
> in massive scale.
>

One company is one company. It's not a variety of people and users.
Scale means nothing if it's not distributed.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:35 AM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > Hmm, the updated Change is mostly okay. I disagree that you have any
> > real security benefits since all the Secure Boot stuff in Linux is
> > still in a bad place.
>
> It's a step into the right direction, but I agree, it alone doesn't
> improve the situation much.  I think we need to overthink the whole
> secure boot signing process in Fedora.  For starters we need to use
> different signing keys for UKI and non-UKI kernels, so it is possible
> (for the user if he chooses so) to disable booting non-UKI kernels to
> really plug the unsigned initrd hole.
>
> shim project planning to move from compiled-in certificates to signed
> certificates in separate files should make it easier to manage this.
>

As part of this, we *really* need to make the process for managing
supported/enabled certificates reasonable and independent of the
firmware restrictions.

> But all that is probably worth a separate change proposal and a separate
> discussion.
>
> > I would like the Change document to be updated
> > to include feedback about Secure Boot in there to further justify how
> > restricted the scope will remain for Phase 1.
> >
> > Additionally, "discoverable partitions" fixes nothing for Fedora right
> > now. There are two problems here:
> > * We don't have a discoverable subvolume specification for Btrfs
> > * Discoverable partition specification falls over dead with snapshots.
> >
> > Don't plan on using systemd-boot. I've said why before in other
> > threads, so I'm not repeating it again.
> >
> > Drop locking out modified kernel command lines. That's pretty much a
> > non-starter.
> >
> > If you want to pursue a Fedora Cloud image with UKIs, please bring it
> > up with the Cloud SIG, keeping in mind the feedback I listed.
>
> Noted.  I'll rework the Change proposal early next year, I'm almost off
> into my xmas holidays.
>

Makes sense. Have a merry Christmas and a happy new year! :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:

> > I understand the big issue you have is that the certificate store for
> > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > NVRAM is limited in size? If that's the big issue you are having then
> > that's absolutely something the Linux community can fix, and can
> > address. Specifically, shim could allow storing the cert store on
> > disk, and authenticate it at boot via the TPM. Not trivial, but
> > doable. And certainly not the firmware's fault...
> >
> > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > the way Linux/shim/mokutil implement the cert db is done the way it is
> > currently done.
>
> Frankly, I'm aggravated by the increased reliance on UEFI features
> without fixing Linux's problems with UEFI features. If we stopped
> relying on UEFI for the cert store, a lot of my issues would go away,
> because then we can design better workflows for managing
> certificates.

Well, the thing is: a chain of trust is a *chain*, hence you must
ultimately hook validation to what the firmware provides you with as
root. And that ultimately is the SecureBoot db on commodity hardware.

If I buy a boring laptop at a store it will come with a UEFI cert
store, and nothing else. Linux cannot really ignore that. If it did,
then you'd not have a trusted boot chain, hence the whole excercsie
would be pointless.

> It makes automation possible, it makes management possible, and it
> opens the doors to experiment with how to do layered images for boot
> (e.g. UKIs + system extension images) without bricking people's
> computers.

As mentioned before: note that the Fedora signing keys are only built
into shim and the kernel, not stored in NVRAM.

But anyway, I think it would be great if shim could manage a cert
store on disk, I already said that. But that's truly orthogonal to
UKIs and sysext really. You keep trying to change topics away from
UKI/sysext towards your general discontent with UEFI.

> That also has the side effect of us having half a chance of being able
> to port this security capability to non-UEFI platforms where we use
> fake UEFI implementations to bootstrap our boot process, because the
> amount of coverage required for fake UEFI implementations is
> considerably lower now.
>
> More generally, relying on UEFI-specific security features when most
> platforms are not being brought up with UEFI is foolish. ARM is almost
> entirely non-UEFI (except the tiny proportion of servers that almost
> no one has) and RISC-V is not a UEFI platform either. POWER uses
> OpenFirmware instead of UEFI, and IBM Z does something else entirely
> different.

Well, "foolish", eyh?

The thing is that chain of trust works quite differently on each such
system (if it exists at all). UEFI is a standardizing and unifying
force that simplifies things greatly, since while not universal it's
still the most widely adopted mechanism (and one of the more
advanced).

Generally, I am very sure we should focus on making the more limited
stuff work like the modern stuff, and not the other way round. For
example, there has already been work on making UKIs boot on grub/MBR,
as mentioned, which is exactly how I think it should be done: move the
old/legacy/simple stuff work more like the
new/modern/featureful/standardized stuff, rather than the other way
round.

> You *need* to think about these problems when designing this stuff.
> You can't take a myopic x86-only view to this. I have not heard of
> anything about UKI security for non-x86 because it seems to all be
> tied up in UEFI stuff.

I work for a company that is working on ARM UEFI systems booting UKIs
in massive scale.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

  Hi,

> Hmm, the updated Change is mostly okay. I disagree that you have any
> real security benefits since all the Secure Boot stuff in Linux is
> still in a bad place.

It's a step into the right direction, but I agree, it alone doesn't
improve the situation much.  I think we need to overthink the whole
secure boot signing process in Fedora.  For starters we need to use
different signing keys for UKI and non-UKI kernels, so it is possible
(for the user if he chooses so) to disable booting non-UKI kernels to
really plug the unsigned initrd hole.

shim project planning to move from compiled-in certificates to signed
certificates in separate files should make it easier to manage this.

But all that is probably worth a separate change proposal and a separate
discussion.

> I would like the Change document to be updated
> to include feedback about Secure Boot in there to further justify how
> restricted the scope will remain for Phase 1.
> 
> Additionally, "discoverable partitions" fixes nothing for Fedora right
> now. There are two problems here:
> * We don't have a discoverable subvolume specification for Btrfs
> * Discoverable partition specification falls over dead with snapshots.
> 
> Don't plan on using systemd-boot. I've said why before in other
> threads, so I'm not repeating it again.
> 
> Drop locking out modified kernel command lines. That's pretty much a
> non-starter.
> 
> If you want to pursue a Fedora Cloud image with UKIs, please bring it
> up with the Cloud SIG, keeping in mind the feedback I listed.

Noted.  I'll rework the Change proposal early next year, I'm almost off
into my xmas holidays.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote:

> When you say it dooesn't get the offsets right, can you elaborate ?

dracut uses fixed offsets for the sections to be placed in memory
in. The values are simply hardcoded, literally specified address
offsets, that worked for the original authors. This typically works –
as long as your sections are not much larger than they were for the
people wo came up with these offsets initially. But as it turns out
this doesn't work for some cases. In such cases the sections will be
loaded into memory overlapped and bad things happen.

ukify hence calculates the offsets manually (by adding up the section
sizes so that this cannot happen.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:58:11AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> > Gerd Hoffmann wrote:
> > > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > > And if you chose your HW carefully you may even be able to register
> > > > your own public keys, generate and sign your own built UKIs and re-
> > > > enable SecureBoot after that... your choice!  
> > > 
> > > And when your hardware doesn't allow that you can still add your own
> > > keys with mokutil so shim.efi will accept your self-signed UKIs.
> > 
> > I'll see when I can take the time for a research project to figure out
> > how customized UKIs can be produced, and develop a tool to do that.
> > Probably never, because I have way too much to do already.
> > 
> > Apparently there is no such tool and no plan to provide one, because
> > surely that would have been mentioned under "User Experience".
> 
> The tools are already there. Essentially, any tool used in koji by the 
> official
> builds is also available to you on your machine.
> 
> There are at three ways that are used: 'dracut --uefi', systemd's ukify, and a
> manual objcopy invocation. The first two are wrappers around objcopy. I'm 
> biased
> because I wrote 'ukify', but I think that's the way to go. What dracut does is
> somewhat primitive and doesn't get the offsets right. Obviously it could be
> improved, but putting the code to generate UKIs inside of an initrd generator 
> is
> a historical accident, and bash is not the nicest language to do offset
> calculations. Thus I hope we can standarize on ukify instead.

When you say it dooesn't get the offsets right, can you elaborate ?
We've been using dracut --uefi to build the UKIs in koji and they
appear to work as expected. Are the offsets only incorrect in
certain circumstances.

We're pretty ambivalent about choice of tool though. We just picked
dracut as it was the first we came across and appeared to work. Any
other tool is viable as then should all (generally) end up doing the
same thing, whichever is most maintainable sounds good.

I can't  argue with Python being better than shell, so ukify certain
wins on that score :-)


> In particular, if some functionality is missing from ukify, feel free to 
> submit
> a PR or an issue. It's in Python, so fairly nice to modify. So far it's been
> written to take a kernel and an initrd and the stub, and produce an efi 
> binary.

Currently we just ask dracut to create the UKI and it creates
the intird as part of that process. If using ukify, we would
ask dracut to create the initrd, and then ask ukify to build
that into a UKI. Its more work, but if ukify does a better
job at the UKI bits that's fine, especially if we'd be suggesting
use of ukify for users in general.


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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 7:32 AM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > If something is proposed for bare metal in the future, then raise
> > > the problems at that point. It is unreasonable to demand that we
> > > fix problems for a use case that is not in scope for what is being
> > > proposed.  Anything related to bare metal was explicitly out of
> > > scope, precisely because it will massively increase the complexity
> > > of what needs to be addressed, making the task infeasible. We need
> > > an incremental path where we can tackle individual practical tasks
> > > rather than trying to solve everything in one go.
> >
> > Yeah, and what happens when it gets punted again when that happens? I
> > do not think it's unreasonable to bring these objections up front when
> > this is clearly marked as a "phase 1" Change that implies UKIs will be
> > used in more and more scenarios over time.
>
> I want UKIs becoming an option in more and more use cases.  I don't
> expect non-UKIs disappearing anytime soon though.  From the updated
> Change page:
>
> 
> long term plan:
> Phase 1: Get the basic building blocks into place, so it is possible
>  to work with and develop for UKIs in virtual machines.
> Phase 2+: Expand UKI support, tackling the use cases which depend on
>   a host-specific initrd or command line (see below) one by one.
> Phase X: Once UKIs have feature parity with non-UKI kernels discuss
>  whenever they should be used by default everywhere (specific
>  use cases like cloud images might switch earlier).
> NOT planed: remove support for non-UKI kernels.
> 
>
> I think at the end of the day this will be somewhat simliar to the Xorg
> -> Wayland transition.  First get basic support there, so it is possible
> to try out stuff, figure what works, figure what needs changes etc.
> Then a (probably long) phase adapting software, fixing bugs found etc,
> making more more use cases being able to work with the new stuff.
> Then at some point eventually flip the default.
>
> One notable difference is that with UKIs there isn't something simliar
> to Xwayland, so flipping the default requires really everything being
> able to work with UKIs.  And flipping the default can only happen for
> new installs, I don't think trying to migrate existing installs to UKIs
> automatically is a sane idea.
>

Hmm, the updated Change is mostly okay. I disagree that you have any
real security benefits since all the Secure Boot stuff in Linux is
still in a bad place. I would like the Change document to be updated
to include feedback about Secure Boot in there to further justify how
restricted the scope will remain for Phase 1.

Additionally, "discoverable partitions" fixes nothing for Fedora right
now. There are two problems here:
* We don't have a discoverable subvolume specification for Btrfs
* Discoverable partition specification falls over dead with snapshots.

Don't plan on using systemd-boot. I've said why before in other
threads, so I'm not repeating it again.

Drop locking out modified kernel command lines. That's pretty much a
non-starter.

If you want to pursue a Fedora Cloud image with UKIs, please bring it
up with the Cloud SIG, keeping in mind the feedback I listed.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

  Hi,

> > If something is proposed for bare metal in the future, then raise
> > the problems at that point. It is unreasonable to demand that we
> > fix problems for a use case that is not in scope for what is being
> > proposed.  Anything related to bare metal was explicitly out of
> > scope, precisely because it will massively increase the complexity
> > of what needs to be addressed, making the task infeasible. We need
> > an incremental path where we can tackle individual practical tasks
> > rather than trying to solve everything in one go.
> 
> Yeah, and what happens when it gets punted again when that happens? I
> do not think it's unreasonable to bring these objections up front when
> this is clearly marked as a "phase 1" Change that implies UKIs will be
> used in more and more scenarios over time.

I want UKIs becoming an option in more and more use cases.  I don't
expect non-UKIs disappearing anytime soon though.  From the updated
Change page:


long term plan:
Phase 1: Get the basic building blocks into place, so it is possible
 to work with and develop for UKIs in virtual machines.
Phase 2+: Expand UKI support, tackling the use cases which depend on
  a host-specific initrd or command line (see below) one by one.
Phase X: Once UKIs have feature parity with non-UKI kernels discuss
 whenever they should be used by default everywhere (specific
 use cases like cloud images might switch earlier).
NOT planed: remove support for non-UKI kernels.


I think at the end of the day this will be somewhat simliar to the Xorg
-> Wayland transition.  First get basic support there, so it is possible
to try out stuff, figure what works, figure what needs changes etc.
Then a (probably long) phase adapting software, fixing bugs found etc,
making more more use cases being able to work with the new stuff.
Then at some point eventually flip the default.

One notable difference is that with UKIs there isn't something simliar
to Xwayland, so flipping the default requires really everything being
able to work with UKIs.  And flipping the default can only happen for
new installs, I don't think trying to migrate existing installs to UKIs
automatically is a sane idea.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 7:07 AM Daniel P. Berrangé  wrote:
>
> On Thu, Dec 22, 2022 at 06:57:07AM -0500, Neal Gompa wrote:
> > On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé  
> > wrote:
> > >
> > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > > > In my case, I have Network Manager config files included in my initrd
> > > > and bootargs to bring up the network so that I get automatic disk
> > > > decryption while on my home network, and prompted for a password when
> > > > I am not at home. I think this a reasonable enough use case it should
> > > > be considered in the long term plan. There was an effort many years
> > > > ago that built the initramfs with the kernel, it was abandoned due to
> > > > not being able to guarantee sources for the binaries in the initramfs,
> > > > trying to dig up the details I am having trouble finding it, but legal
> > > > blocked it there is a reference to it in an old FESCo meeting
> > > > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> > >
> > > I can't see any legal problem with source provision for the
> > > binaries inside the initramfs. We're building the initrds and
> > > UKIs inside koji, so we have a clear record of exactly what
> > > binary RPMs went into the package, and thus have knowledge
> > > of what sources are involved. This is the same situation we
> > > already have in Fedora with libguestfs, where we're building
> > > a disk image inside Koji bundling various binaries. Or for
> > > that matter, not really different from building cloud disk
> > > images, or any other deliverable that bundles together some
> > > binaries from other RPMs and spits out some kind of image
> > > or archive.
> > >
> > > > Additionally, we should also consider
> > > > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > > > implications and why we moved to have kernel-core, kernel-modules, and
> > > > kernel-modules-extra for cloud and different use cases.
> > >
> > > The UKI size for a VM should not be appreciably different from the
> > > combination of the vmluinuz + locally generated initrd. The UKI
> > > will contain a few more modules, as its initrd is built to cope
> > > with Xen, VMware, HyperV + KVM[1], but this only adds a small amount
> > > over a truly minimal initrd targetting 1 hypervisor. So I don't
> > > expect the size of the UKI will be a problem.
> > >
> >
> > You need to add VirtualBox too. That's an incredibly common platform
> > for Fedora to run as a guest.
>
> That's easy enough, what kmod is typically required for disks in
> VirtualBox ?
>

I'm not sure as I don't use VirtualBox myself, but Hans de Geode would
know, since he upstreamed the guest additions some time ago...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 06:57:07AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé  
> wrote:
> >
> > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > > In my case, I have Network Manager config files included in my initrd
> > > and bootargs to bring up the network so that I get automatic disk
> > > decryption while on my home network, and prompted for a password when
> > > I am not at home. I think this a reasonable enough use case it should
> > > be considered in the long term plan. There was an effort many years
> > > ago that built the initramfs with the kernel, it was abandoned due to
> > > not being able to guarantee sources for the binaries in the initramfs,
> > > trying to dig up the details I am having trouble finding it, but legal
> > > blocked it there is a reference to it in an old FESCo meeting
> > > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> >
> > I can't see any legal problem with source provision for the
> > binaries inside the initramfs. We're building the initrds and
> > UKIs inside koji, so we have a clear record of exactly what
> > binary RPMs went into the package, and thus have knowledge
> > of what sources are involved. This is the same situation we
> > already have in Fedora with libguestfs, where we're building
> > a disk image inside Koji bundling various binaries. Or for
> > that matter, not really different from building cloud disk
> > images, or any other deliverable that bundles together some
> > binaries from other RPMs and spits out some kind of image
> > or archive.
> >
> > > Additionally, we should also consider
> > > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > > implications and why we moved to have kernel-core, kernel-modules, and
> > > kernel-modules-extra for cloud and different use cases.
> >
> > The UKI size for a VM should not be appreciably different from the
> > combination of the vmluinuz + locally generated initrd. The UKI
> > will contain a few more modules, as its initrd is built to cope
> > with Xen, VMware, HyperV + KVM[1], but this only adds a small amount
> > over a truly minimal initrd targetting 1 hypervisor. So I don't
> > expect the size of the UKI will be a problem.
> >
> 
> You need to add VirtualBox too. That's an incredibly common platform
> for Fedora to run as a guest.

That's easy enough, what kmod is typically required for disks in
VirtualBox ?

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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

  Hi,

> > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > the way Linux/shim/mokutil implement the cert db is done the way it is
> > currently done.

Well, UEFI *not* defining some standard way to enroll user certificates
actually is part of the problem.  It is one of reasons why shim+mokutil
exist in the first place.

> Frankly, I'm aggravated by the increased reliance on UEFI features
> without fixing Linux's problems with UEFI features. If we stopped
> relying on UEFI for the cert store, a lot of my issues would go away,
> because then we can design better workflows for managing certificates.

Ignoring the UEFI cert store is just not possible, that is the only one
available and used initially.  For booting the bootloader to have to
work with the capabilities provided by the firmware.  Doing something
simliar for ppc would likewise depend on ppc-specific firmware features.

Once shim is loaded both uefi and shim cert stores are available.
Once the kernel is loaded that expands to uefi + shim + kernel.

> It makes automation possible, it makes management possible, and it
> opens the doors to experiment with how to do layered images for boot
> (e.g. UKIs + system extension images) without bricking people's
> computers.

system extensions are verified after the kernel is loaded, so you are
not limited to the uefi/shim cert stores for them.

> That also has the side effect of us having half a chance of being able
> to port this security capability to non-UEFI platforms where we use
> fake UEFI implementations to bootstrap our boot process, because the
> amount of coverage required for fake UEFI implementations is
> considerably lower now.

Yep.  Because it's a standard.  Having u-boot (assuming this is what you
are referring to) provide standard UEFI protocols, then use standard efi
boot process is much less work because there is only one piece in the
boot process which needs to know the hardware specifics.  Which is
u-boot (playing the firmware role on many SBCs).

> More generally, relying on UEFI-specific security features when most
> platforms are not being brought up with UEFI is foolish. ARM is almost
> entirely non-UEFI (except the tiny proportion of servers that almost
> no one has)

Any aarch64 server I boot in some cloud is UEFI.
aarch64 virtual machines use UEFI.
UEFI implementations exist for RPI 3+4.

> and RISC-V is not a UEFI platform either.

https://github.com/tianocore/edk2-platforms/tree/master/Platform/RISC-V/PlatformPkg

> You *need* to think about these problems when designing this stuff.
> You can't take a myopic x86-only view to this. I have not heard of
> anything about UKI security for non-x86 because it seems to all be
> tied up in UEFI stuff.

Booting UKIs in BIOS mode works with a patched grub (needed for hybrid
bios/uefi cloud images).  Of course that doesn't improve security
because the bios lacks the features needed for that.  You can still get
the other advantages UKIs have like a more robust kernel update process.

ppc uses grub too, so being able to boot UKIs on ppc too should be
doable without too much effort when the platform maintainers think
it is useful.

> > Nah. UKIs + sysext are ultimately something that is simpler and much
> > better to test than the current mess. Yeah, for a while we'll have to
> > add complexity because to mechanisms will have to be supported, but
> > eventually things are going to be simple and easier to test.
> 
> Maybe. It's not super intuitive from where I'm standing, and I know
> how all this stuff works.

Because today fedora doesn't use sysexts and doesn't provide much
tooling.

Ideally the packages which drop some dracut module to
/usr/lib/dracut/modules.d/ today will also drop a sysext to the correct
place in the future.  No manual steps needed.  Users don't even need to
know how this works under the hood.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé  wrote:
>
> On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > In my case, I have Network Manager config files included in my initrd
> > and bootargs to bring up the network so that I get automatic disk
> > decryption while on my home network, and prompted for a password when
> > I am not at home. I think this a reasonable enough use case it should
> > be considered in the long term plan. There was an effort many years
> > ago that built the initramfs with the kernel, it was abandoned due to
> > not being able to guarantee sources for the binaries in the initramfs,
> > trying to dig up the details I am having trouble finding it, but legal
> > blocked it there is a reference to it in an old FESCo meeting
> > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
>
> I can't see any legal problem with source provision for the
> binaries inside the initramfs. We're building the initrds and
> UKIs inside koji, so we have a clear record of exactly what
> binary RPMs went into the package, and thus have knowledge
> of what sources are involved. This is the same situation we
> already have in Fedora with libguestfs, where we're building
> a disk image inside Koji bundling various binaries. Or for
> that matter, not really different from building cloud disk
> images, or any other deliverable that bundles together some
> binaries from other RPMs and spits out some kind of image
> or archive.
>
> > Additionally, we should also consider
> > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > implications and why we moved to have kernel-core, kernel-modules, and
> > kernel-modules-extra for cloud and different use cases.
>
> The UKI size for a VM should not be appreciably different from the
> combination of the vmluinuz + locally generated initrd. The UKI
> will contain a few more modules, as its initrd is built to cope
> with Xen, VMware, HyperV + KVM[1], but this only adds a small amount
> over a truly minimal initrd targetting 1 hypervisor. So I don't
> expect the size of the UKI will be a problem.
>

You need to add VirtualBox too. That's an incredibly common platform
for Fedora to run as a guest.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 06:38:56AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé  
> wrote:
> >
> > On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> > > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering  
> > > wrote:
> > > >
> > > > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> > > >
> > > > > > SecureBoot may not be to your liking but is what is installed on 
> > > > > > 99% of
> > > > > > modern hardware sold, so it is a good idea to first show you can
> > > > > > support it. Then if you have interested you can propose "something
> > > > > > better".
> > > > >
> > > > > We have supported Secure Boot for over a decade now. In that 
> > > > > timeframe,
> > > > > literally nobody did anything to make all the workflows you talk about
> > > > > easier and friendlier.
> > > > >
> > > > > In fact, everyone I talk to seems to think it's basically impossible
> > > > > because of how it works at the firmware level.
> > > > >
> > > > > It's telling that neither Windows nor macOS use Secure Boot like Linux
> > > > > does. And they don't precisely for the reasons I outlined.
> > > >
> > > > Yes, Linux never solved the initrd hole so far, but that's not really
> > > > the fault of SecureBoot, it's the fault of Linux if you so
> > > > will. And this proposal is an attempt to finally do something about
> > > > this, and get things in order to actually deliver what the other OSes
> > > > all are delivering.
> > > >
> > > > I understand the big issue you have is that the certificate store for
> > > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > > NVRAM is limited in size? If that's the big issue you are having then
> > > > that's absolutely something the Linux community can fix, and can
> > > > address. Specifically, shim could allow storing the cert store on
> > > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > > doable. And certainly not the firmware's fault...
> > > >
> > > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > > currently done.
> > > >
> > >
> > > Frankly, I'm aggravated by the increased reliance on UEFI features
> > > without fixing Linux's problems with UEFI features. If we stopped
> > > relying on UEFI for the cert store, a lot of my issues would go away,
> > > because then we can design better workflows for managing certificates.
> > > It makes automation possible, it makes management possible, and it
> > > opens the doors to experiment with how to do layered images for boot
> > > (e.g. UKIs + system extension images) without bricking people's
> > > computers.
> >
> > So your objections are completely unrelated to the use of UKIs,
> > and should not be a blocker for this feature proposal. You're
> > just asking people to work on other UEFI related problems.
> >
> 
> It is not unreasonable to have to deal with it for VMs either. Having
> custom drivers needed for workloads where hardware passthrough occurs
> is not unusual. While you can kind of handwave graphics, I've seen
> storage and network devices passed in too.

The initrd  in the UKI only needs to provide kmods needed for getting
the rootfs up, once that's available all other kmods are available.
It is reasonable to assume that any passthrough storage is not likely
to be used for the VM rootfs, instead for data volumes.


> > > Just because today it's only about VMs doesn't mean I can't figure out
> > > you want to do more with it down the road. I want to see some
> > > demonstration of someone actually caring about the user experience for
> > > once with the boot stuff.
> >
> > If something is proposed for bare metal in the future, then raise
> > the problems at that point. It is unreasonable to demand that we
> > fix problems for a use case that is not in scope for what is being
> > proposed.  Anything related to bare metal was explicitly out of
> > scope, precisely because it will massively increase the complexity
> > of what needs to be addressed, making the task infeasible. We need
> > an incremental path where we can tackle individual practical tasks
> > rather than trying to solve everything in one go.
> >
> 
> Yeah, and what happens when it gets punted again when that happens? I
> do not think it's unreasonable to bring these objections up front when
> this is clearly marked as a "phase 1" Change that implies UKIs will be
> used in more and more scenarios over time.

The proposal gives an indication of what's expected

> Also, just because *you* intend it for VMs doesn't mean that's what is
> going to happen. Someone is going to do something to try to use that
> UKI in a bare metal deployment, possibly by using sysexts or squashfs
> or god forbid OCI images.

Well people can do all this today, because they can use dracut
to build a UKI and sign it with certs they're enrolled with
shim. That doesn't imply that

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 08:39:25PM +0100, Iñaki Ucar wrote:
> From the point of view of the workstation experience (with a laptop),
> I see no discussion on how this may impact hibernation. Currently, I
> have secure boot disabled essentially because I want my laptop to
> automatically hibernate (and recover from that state) whenever it is
> suspended for a number of hours. I would like to see a path forward
> here with secure boot enabled.

This proposal does NOT target bare metal, only virtual machines.
Further, it is not removing any existing functionality related
to split vmlinuz + locally generated initrds, nor is is mandating
the use of SecureBoot. IOW, there is zero impact on laptops and
hibernation, nor impact on people who choose to disable SecureBoot

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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> In my case, I have Network Manager config files included in my initrd
> and bootargs to bring up the network so that I get automatic disk
> decryption while on my home network, and prompted for a password when
> I am not at home. I think this a reasonable enough use case it should
> be considered in the long term plan. There was an effort many years
> ago that built the initramfs with the kernel, it was abandoned due to
> not being able to guarantee sources for the binaries in the initramfs,
> trying to dig up the details I am having trouble finding it, but legal
> blocked it there is a reference to it in an old FESCo meeting
> https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.

I can't see any legal problem with source provision for the
binaries inside the initramfs. We're building the initrds and
UKIs inside koji, so we have a clear record of exactly what
binary RPMs went into the package, and thus have knowledge
of what sources are involved. This is the same situation we
already have in Fedora with libguestfs, where we're building
a disk image inside Koji bundling various binaries. Or for
that matter, not really different from building cloud disk
images, or any other deliverable that bundles together some
binaries from other RPMs and spits out some kind of image
or archive.

> Additionally, we should also consider
> https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> implications and why we moved to have kernel-core, kernel-modules, and
> kernel-modules-extra for cloud and different use cases.

The UKI size for a VM should not be appreciably different from the
combination of the vmluinuz + locally generated initrd. The UKI
will contain a few more modules, as its initrd is built to cope
with Xen, VMware, HyperV + KVM[1], but this only adds a small amount
over a truly minimal initrd targetting 1 hypervisor. So I don't
expect the size of the UKI will be a problem.

With regards,
Daniel

[1] 
https://gitlab.com/kraxel/kernel-ark/-/commit/4395c8f99657d14d77622a1845727a4b1ddd6ac6
-- 
|: 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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé  wrote:
>
> On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering  
> > wrote:
> > >
> > > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> > >
> > > > > SecureBoot may not be to your liking but is what is installed on 99% 
> > > > > of
> > > > > modern hardware sold, so it is a good idea to first show you can
> > > > > support it. Then if you have interested you can propose "something
> > > > > better".
> > > >
> > > > We have supported Secure Boot for over a decade now. In that timeframe,
> > > > literally nobody did anything to make all the workflows you talk about
> > > > easier and friendlier.
> > > >
> > > > In fact, everyone I talk to seems to think it's basically impossible
> > > > because of how it works at the firmware level.
> > > >
> > > > It's telling that neither Windows nor macOS use Secure Boot like Linux
> > > > does. And they don't precisely for the reasons I outlined.
> > >
> > > Yes, Linux never solved the initrd hole so far, but that's not really
> > > the fault of SecureBoot, it's the fault of Linux if you so
> > > will. And this proposal is an attempt to finally do something about
> > > this, and get things in order to actually deliver what the other OSes
> > > all are delivering.
> > >
> > > I understand the big issue you have is that the certificate store for
> > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > NVRAM is limited in size? If that's the big issue you are having then
> > > that's absolutely something the Linux community can fix, and can
> > > address. Specifically, shim could allow storing the cert store on
> > > disk, and authenticate it at boot via the TPM. Not trivial, but
> > > doable. And certainly not the firmware's fault...
> > >
> > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > > the way Linux/shim/mokutil implement the cert db is done the way it is
> > > currently done.
> > >
> >
> > Frankly, I'm aggravated by the increased reliance on UEFI features
> > without fixing Linux's problems with UEFI features. If we stopped
> > relying on UEFI for the cert store, a lot of my issues would go away,
> > because then we can design better workflows for managing certificates.
> > It makes automation possible, it makes management possible, and it
> > opens the doors to experiment with how to do layered images for boot
> > (e.g. UKIs + system extension images) without bricking people's
> > computers.
>
> So your objections are completely unrelated to the use of UKIs,
> and should not be a blocker for this feature proposal. You're
> just asking people to work on other UEFI related problems.
>

It is not unreasonable to have to deal with it for VMs either. Having
custom drivers needed for workloads where hardware passthrough occurs
is not unusual. While you can kind of handwave graphics, I've seen
storage and network devices passed in too.

> > > > I assert that the proposal has not yet met the bar to overcome those
> > > > issues.
> > >
> > > If the "those issues" is supposed to be that you hit the size of the
> > > mokutil cert store once, then I fail to see the relationship to
> > > UKI/sysext. After all, the fedora signing keys for sysexts would be
> > > built into the kernel and hence not be charged against NVRAM. And the
> > > fedora UKI is signed with the same key as our current kernels, which
> > > are also not charged against NVRAM but are built into fedora shim. And
> > > the shim signature key is the msft key.
> > >
> > > Yeah, if you want to build your own UKIs + sysext, then you have to
> > > use mokutil to enroll a cert, but it would be entirely sufficient to
> > > enroll one for that, and sign UKIS, kmods, sysext with them.
> > >
> > > (or, maybe you actually hit the NVRAM size limits because you enrolled
> > > hashes, not certs? if so, then maybe address that?)
> > >
> >
> > I do not want to add more things to Fedora that *will* cause people to
> > potentially brick their systems because they have to screw around with
> > UEFI to be able to extend what they can use to boot their systems.
>
> Bricking systems is not an issue for VMs, where this proposal
> is targetted.
>
> > Just because today it's only about VMs doesn't mean I can't figure out
> > you want to do more with it down the road. I want to see some
> > demonstration of someone actually caring about the user experience for
> > once with the boot stuff.
>
> If something is proposed for bare metal in the future, then raise
> the problems at that point. It is unreasonable to demand that we
> fix problems for a use case that is not in scope for what is being
> proposed.  Anything related to bare metal was explicitly out of
> scope, precisely because it will massively increase the complexity
> of what needs to be addressed, making the task infeasible. We need
> an incremental path where we can tackle individual practical

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering  
> wrote:
> >
> > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > > SecureBoot may not be to your liking but is what is installed on 99% of
> > > > modern hardware sold, so it is a good idea to first show you can
> > > > support it. Then if you have interested you can propose "something
> > > > better".
> > >
> > > We have supported Secure Boot for over a decade now. In that timeframe,
> > > literally nobody did anything to make all the workflows you talk about
> > > easier and friendlier.
> > >
> > > In fact, everyone I talk to seems to think it's basically impossible
> > > because of how it works at the firmware level.
> > >
> > > It's telling that neither Windows nor macOS use Secure Boot like Linux
> > > does. And they don't precisely for the reasons I outlined.
> >
> > Yes, Linux never solved the initrd hole so far, but that's not really
> > the fault of SecureBoot, it's the fault of Linux if you so
> > will. And this proposal is an attempt to finally do something about
> > this, and get things in order to actually deliver what the other OSes
> > all are delivering.
> >
> > I understand the big issue you have is that the certificate store for
> > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > NVRAM is limited in size? If that's the big issue you are having then
> > that's absolutely something the Linux community can fix, and can
> > address. Specifically, shim could allow storing the cert store on
> > disk, and authenticate it at boot via the TPM. Not trivial, but
> > doable. And certainly not the firmware's fault...
> >
> > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > the way Linux/shim/mokutil implement the cert db is done the way it is
> > currently done.
> >
> 
> Frankly, I'm aggravated by the increased reliance on UEFI features
> without fixing Linux's problems with UEFI features. If we stopped
> relying on UEFI for the cert store, a lot of my issues would go away,
> because then we can design better workflows for managing certificates.
> It makes automation possible, it makes management possible, and it
> opens the doors to experiment with how to do layered images for boot
> (e.g. UKIs + system extension images) without bricking people's
> computers.

So your objections are completely unrelated to the use of UKIs,
and should not be a blocker for this feature proposal. You're
just asking people to work on other UEFI related problems.

> > > I assert that the proposal has not yet met the bar to overcome those
> > > issues.
> >
> > If the "those issues" is supposed to be that you hit the size of the
> > mokutil cert store once, then I fail to see the relationship to
> > UKI/sysext. After all, the fedora signing keys for sysexts would be
> > built into the kernel and hence not be charged against NVRAM. And the
> > fedora UKI is signed with the same key as our current kernels, which
> > are also not charged against NVRAM but are built into fedora shim. And
> > the shim signature key is the msft key.
> >
> > Yeah, if you want to build your own UKIs + sysext, then you have to
> > use mokutil to enroll a cert, but it would be entirely sufficient to
> > enroll one for that, and sign UKIS, kmods, sysext with them.
> >
> > (or, maybe you actually hit the NVRAM size limits because you enrolled
> > hashes, not certs? if so, then maybe address that?)
> >
> 
> I do not want to add more things to Fedora that *will* cause people to
> potentially brick their systems because they have to screw around with
> UEFI to be able to extend what they can use to boot their systems.

Bricking systems is not an issue for VMs, where this proposal
is targetted.

> Just because today it's only about VMs doesn't mean I can't figure out
> you want to do more with it down the road. I want to see some
> demonstration of someone actually caring about the user experience for
> once with the boot stuff.

If something is proposed for bare metal in the future, then raise
the problems at that point. It is unreasonable to demand that we
fix problems for a use case that is not in scope for what is being
proposed.  Anything related to bare metal was explicitly out of
scope, precisely because it will massively increase the complexity
of what needs to be addressed, making the task infeasible. We need
an incremental path where we can tackle individual practical tasks
rather than trying to solve everything in one go.

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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> In my case, I have Network Manager config files included in my initrd
> and bootargs to bring up the network so that I get automatic disk
> decryption while on my home network, and prompted for a password when
> I am not at home. I think this a reasonable enough use case it should
> be considered in the long term plan. There was an effort many years
> ago that built the initramfs with the kernel, it was abandoned due to
> not being able to guarantee sources for the binaries in the initramfs,

If a UKI is built in koji, the initrd it embeds must also be built in koji. And
when the initrd is built in koji, it is just taking some binaries from rpms and
repacking them. We ensure that we have an srpm for any official srpm. Thus, 
going
back from the UKI, you look up the initrd, and the logs for the initrd build,
and get a list of rpms, and then look the appropriate srpms from that, and from
the srpms you get the sources. There's a few more steps, but the availability of
sources is guaranteed using the mechanism existing for normal rpms.

> trying to dig up the details I am having trouble finding it, but legal
> blocked it there is a reference to it in an old FESCo meeting
> https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> Additionally, we should also consider
> https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> implications and why we moved to have kernel-core, kernel-modules, and
> kernel-modules-extra for cloud and different use cases.

Yes. That's why this proposal explicitly targets a narrow use case which doesn't
need many drivers and will support many different machines with the same
(relatively small) initrd.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 5:58 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> > Gerd Hoffmann wrote:
> > > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > > And if you chose your HW carefully you may even be able to register
> > > > your own public keys, generate and sign your own built UKIs and re-
> > > > enable SecureBoot after that... your choice!
> > >
> > > And when your hardware doesn't allow that you can still add your own
> > > keys with mokutil so shim.efi will accept your self-signed UKIs.
> >
> > I'll see when I can take the time for a research project to figure out
> > how customized UKIs can be produced, and develop a tool to do that.
> > Probably never, because I have way too much to do already.
> >
> > Apparently there is no such tool and no plan to provide one, because
> > surely that would have been mentioned under "User Experience".
>
> The tools are already there. Essentially, any tool used in koji by the 
> official
> builds is also available to you on your machine.
>
> There are at three ways that are used: 'dracut --uefi', systemd's ukify, and a
> manual objcopy invocation. The first two are wrappers around objcopy. I'm 
> biased
> because I wrote 'ukify', but I think that's the way to go. What dracut does is
> somewhat primitive and doesn't get the offsets right. Obviously it could be
> improved, but putting the code to generate UKIs inside of an initrd generator 
> is
> a historical accident, and bash is not the nicest language to do offset
> calculations. Thus I hope we can standarize on ukify instead.
>
> In particular, if some functionality is missing from ukify, feel free to 
> submit
> a PR or an issue. It's in Python, so fairly nice to modify. So far it's been
> written to take a kernel and an initrd and the stub, and produce an efi 
> binary.
> It could be extended to start with an existing efi binary and e.g. a new 
> initrd
> or a different commandline, but so far nobody has requested that.
>

It would definitely make sense to add some documentation about
preferred tools, since other distributions will eventually reference
our Change document to do UKIs on their own too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> Gerd Hoffmann wrote:
> > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > And if you chose your HW carefully you may even be able to register
> > > your own public keys, generate and sign your own built UKIs and re-
> > > enable SecureBoot after that... your choice!  
> > 
> > And when your hardware doesn't allow that you can still add your own
> > keys with mokutil so shim.efi will accept your self-signed UKIs.
> 
> I'll see when I can take the time for a research project to figure out
> how customized UKIs can be produced, and develop a tool to do that.
> Probably never, because I have way too much to do already.
> 
> Apparently there is no such tool and no plan to provide one, because
> surely that would have been mentioned under "User Experience".

The tools are already there. Essentially, any tool used in koji by the official
builds is also available to you on your machine.

There are at three ways that are used: 'dracut --uefi', systemd's ukify, and a
manual objcopy invocation. The first two are wrappers around objcopy. I'm biased
because I wrote 'ukify', but I think that's the way to go. What dracut does is
somewhat primitive and doesn't get the offsets right. Obviously it could be
improved, but putting the code to generate UKIs inside of an initrd generator is
a historical accident, and bash is not the nicest language to do offset
calculations. Thus I hope we can standarize on ukify instead.

In particular, if some functionality is missing from ukify, feel free to submit
a PR or an issue. It's in Python, so fairly nice to modify. So far it's been
written to take a kernel and an initrd and the stub, and produce an efi binary.
It could be extended to start with an existing efi binary and e.g. a new initrd
or a different commandline, but so far nobody has requested that.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-22 Thread Javier Martinez Canillas

On Wed, Dec 21, 2022 at 6:13 PM Demi Marie Obenour
 wrote:
>

[...]

>
> Does vfat support atomic rename?  Is it possible to atomically upgrade
> a bootloader/UKI/etc?
> --

For Linux, renameat2 RENAME_EXCHANGE is supported in vfat since
version v6.0. The relevant commits FYI are:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=019a0c9e377c
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=204d03203a14
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da87e1725ae2

Best regards,
Javier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 05:44:36PM +0100, Lennart Poettering wrote:
> 
> I mean, sure, if you use the Fedora supplied vanilla signed UKI
> without anything else then it won't boot from a network, because that
> would be a security hole. But I see no reason why a network boot UKI
> couldn't be build that maybe be booted via PXE and derives root fs
> info from DHCP alone.

I expect that is an area where we have to research how we want build
stuff in the future.  The UKI for virtual machines / cloud images is
simple and static enough that we can just build that as part of the
kernel build process.  For other use cases that might not be the best
approach though.

Also note that UKIs can be booted without an bootloader.  It's an EFI
binary the firmware can handle on its own.  That actually simplifies
network booting, your dhcp server can hand out URLs to the UKI.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering  wrote:
>
> On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > SecureBoot may not be to your liking but is what is installed on 99% of
> > > modern hardware sold, so it is a good idea to first show you can
> > > support it. Then if you have interested you can propose "something
> > > better".
> >
> > We have supported Secure Boot for over a decade now. In that timeframe,
> > literally nobody did anything to make all the workflows you talk about
> > easier and friendlier.
> >
> > In fact, everyone I talk to seems to think it's basically impossible
> > because of how it works at the firmware level.
> >
> > It's telling that neither Windows nor macOS use Secure Boot like Linux
> > does. And they don't precisely for the reasons I outlined.
>
> Yes, Linux never solved the initrd hole so far, but that's not really
> the fault of SecureBoot, it's the fault of Linux if you so
> will. And this proposal is an attempt to finally do something about
> this, and get things in order to actually deliver what the other OSes
> all are delivering.
>
> I understand the big issue you have is that the certificate store for
> Linux (i.e. the mokutil db) is limited in size because EFI variable
> NVRAM is limited in size? If that's the big issue you are having then
> that's absolutely something the Linux community can fix, and can
> address. Specifically, shim could allow storing the cert store on
> disk, and authenticate it at boot via the TPM. Not trivial, but
> doable. And certainly not the firmware's fault...
>
> I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> the way Linux/shim/mokutil implement the cert db is done the way it is
> currently done.
>

Frankly, I'm aggravated by the increased reliance on UEFI features
without fixing Linux's problems with UEFI features. If we stopped
relying on UEFI for the cert store, a lot of my issues would go away,
because then we can design better workflows for managing certificates.
It makes automation possible, it makes management possible, and it
opens the doors to experiment with how to do layered images for boot
(e.g. UKIs + system extension images) without bricking people's
computers.

That also has the side effect of us having half a chance of being able
to port this security capability to non-UEFI platforms where we use
fake UEFI implementations to bootstrap our boot process, because the
amount of coverage required for fake UEFI implementations is
considerably lower now.

More generally, relying on UEFI-specific security features when most
platforms are not being brought up with UEFI is foolish. ARM is almost
entirely non-UEFI (except the tiny proportion of servers that almost
no one has) and RISC-V is not a UEFI platform either. POWER uses
OpenFirmware instead of UEFI, and IBM Z does something else entirely
different.

You *need* to think about these problems when designing this stuff.
You can't take a myopic x86-only view to this. I have not heard of
anything about UKI security for non-x86 because it seems to all be
tied up in UEFI stuff.

Coming back to "my issue", I've had this problem for six years, and
for most of it "the Linux community" (specifically the Linux boot
community) has brushed me off saying my issue doesn't matter. Even if
it leads to bricked systems. Even if it makes it hard for people to
use their computers. Even if it leads to people turning off Secure
Boot. And finally, even if it means people don't use Linux at all
because they can't make it work.

> > > Finally, unless this proposal harms Fedora I do not see why oppose it.
> > > If, as you fear, it won't work ... then it won't and we'll try
> > > something else. However, having some knowledge of the (security side of
> > > the) matter I do not see why it wouldn't work, once all the pieces fall
> > > in place.
> >
> > This adds significant complexity to the Fedora kernel package and it
> > effectively increases what we need to test for virtualized Fedora Linux
> > environments.
>
> Nah. UKIs + sysext are ultimately something that is simpler and much
> better to test than the current mess. Yeah, for a while we'll have to
> add complexity because to mechanisms will have to be supported, but
> eventually things are going to be simple and easier to test.
>

Maybe. It's not super intuitive from where I'm standing, and I know
how all this stuff works.

> > I assert that the proposal has not yet met the bar to overcome those
> > issues.
>
> If the "those issues" is supposed to be that you hit the size of the
> mokutil cert store once, then I fail to see the relationship to
> UKI/sysext. After all, the fedora signing keys for sysexts would be
> built into the kernel and hence not be charged against NVRAM. And the
> fedora UKI is signed with the same key as our current kernels, which
> are also not charged against NVRAM but are built into fedora shim. And
> the shim signature key is the msft key.
>
> Yeah, if you want to

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and remains in unswappable memory
> > - root= syntax is limited to what the kernel understands, i.e.
> >   no root=UUID=… o root=/dev/disk/by-path/… or other udev links,
> >   no encryption or dm-verity.
> > - no bluetooth keyboards or other fancy peripherals
> > - recovery is pretty hard
> 
> Also, the security lock-down for the kernel command line means:
> - no network root filesystem
> - no boot-time-only kernel/module configuration
> 
> The idea of switching from grub2 to sd-boot would also drop network boot
> and BIOS support.  Supporting boot loaders seems to be a bit of a issue
> sometimes, so trying to support multiple boot loaders seems like a bad
> idea to me.

The switch to BootLoaderSpec made switching boot loaders *much* easier.
The actual boot loader config is fixed and never touched, kernel updates
add/remove BLS config snippets, and all boot loaders handle that just
fine.

You can even have *two* bootloaders, sd-boot for efi mode and grub2 for
bios mode.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Iñaki Ucar

From the point of view of the workstation experience (with a laptop),
I see no discussion on how this may impact hibernation. Currently, I
have secure boot disabled essentially because I want my laptop to
automatically hibernate (and recover from that state) whenever it is
suspended for a number of hours. I would like to see a path forward
here with secure boot enabled.

Thanks,
Iñaki

On Tue, 20 Dec 2022 at 16:22, Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
>
> == Summary ==
> Add support for unified kernels images to Fedora.
>
> == Owner ==
> * Name: [[User:kraxel| Gerd Hoffmann]]
> * Email: kra...@redhat.com
>
>
> == Detailed Description ==
> The goal is to move away from initrd images being generated on the
> installed machine.  They are generated while building the kernel
> package instead, then shipped as part of a unified kernel image.
>
> A unified kernel image is an all-in-one efi binary containing kernel,
> initrd, cmdline and signature.  The secure boot signature covers
> everything, specifically the initrd is included which is not the case
> when the initrd gets loaded as separate file from /boot.
>
> Main motivation for this move is to make the distro more robust and more 
> secure.
>
> Switching the whole distro over to unified kernels quickly is not
> realistic though.  Too many features are depending on the current
> workflow with a host-specific initrd (and host-specific kernel command
> line), which is fundamentally incompatible with unified kernels where
> everybody will have the same initrd and command line. Thats why there
> is 'Phase 1' in title, so we can have more Phases in future releases
> 
>
> A host-specific initrd / command line is needed today for:
>
> * features needing optional dracut modules (initrd rebuild needed to
> enable them).
> * configuration / secrets baked into the initrd (booting from iscsi
> for example).
> * configuration being specified on the kernel command line.
> ** root filesystem being the most important one.
> [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions]
> allow to remove this.
>
> Phase 1 goals (high priority):
>
> * Ship a unified kernel image as (optional) kernel sub-rpm.  Users can
> opt-in to use that kernel by installing the sub-rpm.  Initial focus is
> on booting virtual machines where we have a relatively small and well
> defined set of drivers / features needed.  Supporting modern physical
> machines with standard setup (i.e. boot from local sata/nvme storage)
> too should be easy.
> * Update kernel install scripts so unified kernels are installed and
> updated properly.
> * Add bootloader support for unified kernel images.  Add
> [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
> unified kernel bls support] to grub2, or support using systemd-boot,
> or both.
>
> Phase 1 goals (lower priority, might move to Phase 2):
>
> * Add proper discoverable partitions support to installers (anaconda,
> image builder, ...).
> ** Temporary workaround possible: set types using sfdisk in %post script.
> ** When using btrfs: configure 'root' subvolume as default volume.
> * Add proper systemd-boot support to installers.
> ** Temporary workaround possible: run 'bootctl install' in %post script.
> * Better measurement and remote attestation support.
> ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to
> allow pre-calculate TPM PCR values.
> ** avoid using grub2 (measures every config file line executed which
> is next to impossible to pre-calculate).
> * Switch cloud images to use unified kernels.
>
> Phase 2/3 goals (longer-term stuff which is not realistic to complete for 
> F38).
>
> * Move away from using the kernel command line for configuration.
> * Move away from storing secrets in the initrd.
> * Handle dracut optional modules in a different way.
>
> systemd has some building blocks which can be used, although none of
> them are used by fedora today.
> [https://www.freedesktop.org/software/systemd/man/systemd-creds.html
> systemd credentials] can be used for secrets (also for configuration).
> The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html
> unified kernel stub] can load credentials from the ESP.
>
> The unified kernel stub can also load
> [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html
> extensions] from the ESP, which can possibly be used to replace
> optional dracut modules.
>
> == Feedback ==
>
>
> == Benefit to Fedora ==
> * Better secure boot support (specifically the initrd is covered by
> the signature).
> * Better confidential computing support (measurements are much more
> useful if we know what hashes to expect for the

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:

> > SecureBoot may not be to your liking but is what is installed on 99% of
> > modern hardware sold, so it is a good idea to first show you can
> > support it. Then if you have interested you can propose "something
> > better".
>
> We have supported Secure Boot for over a decade now. In that timeframe,
> literally nobody did anything to make all the workflows you talk about
> easier and friendlier.
>
> In fact, everyone I talk to seems to think it's basically impossible
> because of how it works at the firmware level.
>
> It's telling that neither Windows nor macOS use Secure Boot like Linux
> does. And they don't precisely for the reasons I outlined.

Yes, Linux never solved the initrd hole so far, but that's not really
the fault of SecureBoot, it's the fault of Linux if you so
will. And this proposal is an attempt to finally do something about
this, and get things in order to actually deliver what the other OSes
all are delivering.

I understand the big issue you have is that the certificate store for
Linux (i.e. the mokutil db) is limited in size because EFI variable
NVRAM is limited in size? If that's the big issue you are having then
that's absolutely something the Linux community can fix, and can
address. Specifically, shim could allow storing the cert store on
disk, and authenticate it at boot via the TPM. Not trivial, but
doable. And certainly not the firmware's fault...

I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
the way Linux/shim/mokutil implement the cert db is done the way it is
currently done.

> > Finally, unless this proposal harms Fedora I do not see why oppose it.
> > If, as you fear, it won't work ... then it won't and we'll try
> > something else. However, having some knowledge of the (security side of
> > the) matter I do not see why it wouldn't work, once all the pieces fall
> > in place.
>
> This adds significant complexity to the Fedora kernel package and it
> effectively increases what we need to test for virtualized Fedora Linux
> environments.

Nah. UKIs + sysext are ultimately something that is simpler and much
better to test than the current mess. Yeah, for a while we'll have to
add complexity because to mechanisms will have to be supported, but
eventually things are going to be simple and easier to test.

> I assert that the proposal has not yet met the bar to overcome those
> issues.

If the "those issues" is supposed to be that you hit the size of the
mokutil cert store once, then I fail to see the relationship to
UKI/sysext. After all, the fedora signing keys for sysexts would be
built into the kernel and hence not be charged against NVRAM. And the
fedora UKI is signed with the same key as our current kernels, which
are also not charged against NVRAM but are built into fedora shim. And
the shim signature key is the msft key.

Yeah, if you want to build your own UKIs + sysext, then you have to
use mokutil to enroll a cert, but it would be entirely sufficient to
enroll one for that, and sign UKIS, kmods, sysext with them.

(or, maybe you actually hit the NVRAM size limits because you enrolled
hashes, not certs? if so, then maybe address that?)

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Di, 20.12.22 21:32, Neal Gompa (ngomp...@gmail.com) wrote:

> As someone whose day job involves working with teams who develop both
> Windows and Linux drivers (and in the past, even macOS drivers!), I
> can categorically say that Windows driver engineering processes are
> way friendlier than Linux ones, precisely because Windows drivers are
> deliberately not exposed to Secure Boot *at all*. Running development
> versions of drivers just requires installing a development certificate
> into the NT kernel certificate store. The equivalent process for Linux
> is to load a custom secure boot certificate into firmware, which is
> fraught with peril and potentially not even possible.

This is a bit of a misrepresentation how this currently works.

The Linux kernel populates its keyrings these days from both built-in
keys and from those imported from uefi vars (both uefi db and mokutil
stuff).

So, yes, SecureBoot keys are imported into the kernel keyring, but
they aren't the only thing. You can enroll your own via mokutil and
the OS vendor can enroll by building them into the kernel. Neither of
those two has much to do with firmware, i.e. there's no need to update
the UEFI db, updating the mokutil efi vars is enough.

> I cannot tell you how many times I've bricked a system by attempting
> to load another cert only to find out there's not enough space and
> the firmware didn't handle that well.

Well, sure, space in the efi vars is limited. But christ, how many
certs did you actually enroll via mokutil? (if you are working with
local throw-away certs, then I guess it's just not build for that)

I mean, sure, it would make sense of shim would be able to manage a
keyring on a file in the ESP instead of purely via an efi var, but
this massively raises the question of authenticating that. i.e. would
require some TPM protection usually, but TPM from UEFI mode is not
fun, since (except for PCR measurements) you have to roll the TPM
communication yourself (or embedd a fill TPM stack, but thta's going
to make shim even larger than it already is).

I mean, file an RFE against shim.

But this really has nothing to do with UKIs/sysext, we just use the
same authentication mechanisms as before pretty much: UKIs are
authenticated like any kernels, just as before, and sysext are
authenticated via the same keyring as kmods basically. Hence there's
nothing really new here when it comes to key management.

If you have beef with how Linux manages the keys for authenticating
kmods then bring that up with the kernel community, it has nothing to
do with the way UKIs/sysext works.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Di, 20.12.22 11:28, Neal Gompa (ngomp...@gmail.com) wrote:

> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really interact with real users enough to
> understand how much of a problem they actually are.

I presume this is supposed to be a comment on systemd upstream, which
includes me?

Dunno, I think I have quite a good idea how people use systemd, and
how general purpose distros like Fedora use it. Because I get the
firehose of feedback on it. From *all* distros, and from all ways how
peole use it.

> In the Fedora case, things are simpler right up until we hit graphics
> drivers. This is also a problem for VMs too, because GPU passthrough
> is a common case for scientific and gaming workloads. As long as the
> NVIDIA driver remains dominant in Linux, UKIs cannot work because by
> design you cannot load anything that isn't part of the kernel image.

That's simply not true. Along with UKIs we developed the "sysext"
concept, to make them extensible. Primary usecase: extend the basic
initrd with drivers/subsystems that you want on some systems but not all.

> For bare metal, we *need* these drivers in early boot, though. And
> that's another problem: no third-party early boot drivers. Even if you
> solve the signing issue, you need to introduce some kind of two-stage
> OS boot process so we can bring up the bare minimum to load a second
> image containing all the remaining drivers.

In the UKI model the UEFI stub (i.e. systemd-stub) actually loads the
sysext images from UEFI mode still, via UEFI fs APIs. i.e. they area
already in memory when the initrd initializes, and can be used
instantly. They are validated via verity/kernel certification
keyring.

> And at that point, you've
> defeated the purpose of UKIs. I've heard from some people that system
> extensions (sysexts) would be a way to solve this, and maybe it is.
> But again, we've eliminated the value of UKIs by doing so.

I don't see any value being "eliminated".

> Speaking more broadly, there are also problems that will be introduced
> as this trickles down from Fedora into prominent downstreams (assuming
> this is accepted). In the RHEL case, you've basically broken driver
> disks completely. In the UKI model, there's no way to incorporate
> early boot storage, network, and graphics drivers.

There is, sysext.

> The crux of the problem here is *signing*. All of this is tied up in
> Secure Boot and TPM, which is the wrong place to actually handle
> this.

sysext authentication is tied to kernel keyring authentication
actually, exactly like kernel modules.

The kernel keyring can be populated via mokutil.

> In other operating systems (notably Windows), Secure Boot certificates
> are not used for blocking or enabling kernel-level drivers. Instead,
> there's a kernel-level certificate store that is used to validate and
> enable drivers, allowing everything to be managed in a hardware
> platform agnostic way.

I think people currently accept that mokutil is the certificate store
for Linux. If you don't like that, I might even agree to some point
with that, but this isn't new in the context of UKIs or sysext, we
just use the very same infrastructure kmods use.

> I've also yet to hear of a decent reason for
> TPM measurements too. Block or filesystem verity provides similar
> guarantees to provide tamper resistance and are both much easier to
> debug than TPM interfaces.

Unlocking secrets via TPM is usually what you want for write
acccess. Verity is read-only only.

> With my FESCo hat on, I'm uneasy about this change. With my "Fedora
> user and advocate" hat on, I think that the UAPI group has failed to
> provide something useful to the Linux world here and I would be
> extremely apprehensive about Fedora adopting any portion of this
> stuff.

Umpfh. This is FUD. Please read up before writing scathing comments
like that.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Dennis Gilmore via devel

In my case, I have Network Manager config files included in my initrd
and bootargs to bring up the network so that I get automatic disk
decryption while on my home network, and prompted for a password when
I am not at home. I think this a reasonable enough use case it should
be considered in the long term plan. There was an effort many years
ago that built the initramfs with the kernel, it was abandoned due to
not being able to guarantee sources for the binaries in the initramfs,
trying to dig up the details I am having trouble finding it, but legal
blocked it there is a reference to it in an old FESCo meeting
https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
Additionally, we should also consider
https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
implications and why we moved to have kernel-core, kernel-modules, and
kernel-modules-extra for cloud and different use cases.

Dennis

On Tue, Dec 20, 2022 at 9:22 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
>
> == Summary ==
> Add support for unified kernels images to Fedora.
>
> == Owner ==
> * Name: [[User:kraxel| Gerd Hoffmann]]
> * Email: kra...@redhat.com
>
>
> == Detailed Description ==
> The goal is to move away from initrd images being generated on the
> installed machine.  They are generated while building the kernel
> package instead, then shipped as part of a unified kernel image.
>
> A unified kernel image is an all-in-one efi binary containing kernel,
> initrd, cmdline and signature.  The secure boot signature covers
> everything, specifically the initrd is included which is not the case
> when the initrd gets loaded as separate file from /boot.
>
> Main motivation for this move is to make the distro more robust and more 
> secure.
>
> Switching the whole distro over to unified kernels quickly is not
> realistic though.  Too many features are depending on the current
> workflow with a host-specific initrd (and host-specific kernel command
> line), which is fundamentally incompatible with unified kernels where
> everybody will have the same initrd and command line. Thats why there
> is 'Phase 1' in title, so we can have more Phases in future releases
> 
>
> A host-specific initrd / command line is needed today for:
>
> * features needing optional dracut modules (initrd rebuild needed to
> enable them).
> * configuration / secrets baked into the initrd (booting from iscsi
> for example).
> * configuration being specified on the kernel command line.
> ** root filesystem being the most important one.
> [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions]
> allow to remove this.
>
> Phase 1 goals (high priority):
>
> * Ship a unified kernel image as (optional) kernel sub-rpm.  Users can
> opt-in to use that kernel by installing the sub-rpm.  Initial focus is
> on booting virtual machines where we have a relatively small and well
> defined set of drivers / features needed.  Supporting modern physical
> machines with standard setup (i.e. boot from local sata/nvme storage)
> too should be easy.
> * Update kernel install scripts so unified kernels are installed and
> updated properly.
> * Add bootloader support for unified kernel images.  Add
> [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
> unified kernel bls support] to grub2, or support using systemd-boot,
> or both.
>
> Phase 1 goals (lower priority, might move to Phase 2):
>
> * Add proper discoverable partitions support to installers (anaconda,
> image builder, ...).
> ** Temporary workaround possible: set types using sfdisk in %post script.
> ** When using btrfs: configure 'root' subvolume as default volume.
> * Add proper systemd-boot support to installers.
> ** Temporary workaround possible: run 'bootctl install' in %post script.
> * Better measurement and remote attestation support.
> ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to
> allow pre-calculate TPM PCR values.
> ** avoid using grub2 (measures every config file line executed which
> is next to impossible to pre-calculate).
> * Switch cloud images to use unified kernels.
>
> Phase 2/3 goals (longer-term stuff which is not realistic to complete for 
> F38).
>
> * Move away from using the kernel command line for configuration.
> * Move away from storing secrets in the initrd.
> * Handle dracut optional modules in a different way.
>
> systemd has some building blocks which can be used, although none of
> them are used by fedora today.
> [https://www.freedesktop.org/software/systemd/man/systemd-creds.html
> systemd credentials] can be used for secrets (also for configuration).
> The

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 12:38, Neal Gompa (ngomp...@gmail.com) wrote:

> > sd-boot implements boot counting by stashing the counter inside the
> > UKI (or bootspec type #1 conf file) file name, so that the counter is
> > impossible to ever get lost, pile up or so.
>
> Because the ESP is intended to be shared, and these days /boot is not.
> Unshared boot content should not be in a shared space.

This is wrong on two levels:

1. The boot loader should process all UKIs from all installed OSes,
   hence the UKIs should be dropped in in a *shared* directory, not a
   private directory. It's the idea of the boot loader spec to make
   the drop-in dir shared between Linux OSes.

2. The UEFI spec defines clearly where OSes should put private stuff
   in the ESP if they have any (see https://uefi.org/registry for
   example, fedora is listed there btw). The ESP is very clearly
   defined both in terms for shared resources and for private
   resources.

I am not sure what you intend to put in /boot? If it's UKIs then
please notice that these are a single file per kernel/initrd combo,
and that is inherently placed in a shared dir, you need nothing else
really.

> We can only really have one boot manager, especially with how broken
> multiple ESPs on a system are.

Why would you have multiple ESPs? I don't follow?

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Björn Persson

Gerd Hoffmann wrote:
> On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > And if you chose your HW carefully you may even be able to register
> > your own public keys, generate and sign your own built UKIs and re-
> > enable SecureBoot after that... your choice!  
> 
> And when your hardware doesn't allow that you can still add your own
> keys with mokutil so shim.efi will accept your self-signed UKIs.

I'll see when I can take the time for a research project to figure out
how customized UKIs can be produced, and develop a tool to do that.
Probably never, because I have way too much to do already.

Apparently there is no such tool and no plan to provide one, because
surely that would have been mentioned under "User Experience".

Björn Persson


pgpMf3pOAD4my.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Björn Persson

Gerd Hoffmann wrote:
> On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> > > Switching the whole distro over to unified kernels quickly is not
> > > realistic though.  Too many features are depending on the current
> > > workflow with a host-specific initrd (and host-specific kernel command
> > > line), which is fundamentally incompatible with unified kernels where
> > > everybody will have the same initrd and command line. Thats why there
> > > is 'Phase 1' in title, so we can have more Phases in future releases
> > >   
> > 
> > Whew! So usable kernels won't go away in F38. I only have to worry
> > about being forced to build my own kernels in some unspecified future
> > phase. Doom is still coming but no one knows when. That's *such* a
> > relief.  
> 
> Note the proposal talks about adding support for ukis, not about
> removing support for current separate kernel+initrd setup.

That's not how I read "switching the whole distro over". Switching over
means to remove the old thing and use only the new thing.

I see you have changed that in the wiki. The change proposal looks less
scary now.

Björn Persson


pgpGBZkeyfaau.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 12:35, Neal Gompa (ngomp...@gmail.com) wrote:

> > And similar for server/embedded stuff. If fedora wants to be deployed
> > in such worlds, it's kinda nice if we can automatically recover from
> > hosed updates.
>
> None of those things require us to write data to /boot. Even in your
> model, if you *must* write to a filesystem, the counters can live on
> the ESP even if all the system-installed content exists in /boot. I'm
> sure you could envision a simple file in the ESP for that. None of
> that is permanent configuration, just transient stuff.

I don't follow your thinking at all. On one hand you want /boot/ to be
ext4, supposedly for data safety reasons. But you don't want writes
from pre-boot environment to go there. You are fine if pre-boot writes
to ESP (i.e. VFAT) however for boot counting.

So, ESP is more important for booting than /boot/ (simply because a
hosed kernel doesn't matter, if you have another — a hosed boot loader
is much more problematic however since you typically have no other),
hence if anything you should be more concerned about writes there than
on /boot.

If you accept that writes to the ESP/VFAT are actually OK, then I
think it's just a minor step to say that /boot/ as VFAT is also OK
given these writes are more seldom, are done from the safer OS
environment, and can be tightly controlled.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Dec 20, 2022 at 11:28:48AM -0500, Neal Gompa wrote:
> On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton  wrote:
> > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really interact with real users enough to
> understand how much of a problem they actually are.

You're painting with a very wide brush here. The concept of UKIs has been in
development for a long time. [1] adds the initial implementation of sd-stub in
systemd, and that commit is from 2015!  Many, many people have been working on
the details of the concept and vying to make the implementation better. That
group includes most maintainers of systemd, but also external contributors.
Accusing us of not interacting with "real users" is strange.

[1] https://github.com/systemd/systemd/commit/0fa2cac4f0cdefaf1

> I realize that
> this Change is only about VMs, but since it explicitly talks about it
> being "phase 1", the implication is that future Changes are coming to
> switch fully over. Consequently, I'm going to provide much more
> holistic feedback instead of just nitpicking on this case.

I think that limiting this Change to VMs is a very smart move. It is a very
clear case that we can actually tackle right now, and we generally know what
concepts we need to cover it, and the code is either there or at least under
significant development. Let's do this one thing right and learn from the
experience.

> In the Fedora case, things are simpler right up until we hit graphics
> drivers. This is also a problem for VMs too, because GPU passthrough
> is a common case for scientific and gaming workloads. As long as the
> NVIDIA driver remains dominant in Linux, UKIs cannot work because by
> design you cannot load anything that isn't part of the kernel image.
> For bare metal, we *need* these drivers in early boot, though. And
> that's another problem: no third-party early boot drivers. Even if you
> solve the signing issue, you need to introduce some kind of two-stage
> OS boot process so we can bring up the bare minimum to load a second
> image containing all the remaining drivers. And at that point, you've
> defeated the purpose of UKIs. I've heard from some people that system
> extensions (sysexts) would be a way to solve this, and maybe it is.
> But again, we've eliminated the value of UKIs by doing so.
>
> Speaking more broadly, there are also problems that will be introduced
> as this trickles down from Fedora into prominent downstreams (assuming
> this is accepted). In the RHEL case, you've basically broken driver
> disks completely. In the UKI model, there's no way to incorporate
> early boot storage, network, and graphics drivers. This is
> *incredibly* common for RHEL administrators because there's a general
> acceptance of proprietary kernel modules from vendors these days. Even
> ignoring those, Red Hat's kernel feature support mindset is completely
> incompatible with UKIs, because RHEL does default-off rather than
> Fedora's default-on model for kernel features. We could debate until
> the cows come home on whether it's right or wrong, but their current
> mindset essentially means tons of common hardware becomes unsupported
> quite regularly. The ELRepo project is popular among RHEL folks
> because it restores those drivers and makes it possible to use RHEL on
> those machines through a combination of driver disks and kernel module
> packages.
> 
> The crux of the problem here is *signing*. All of this is tied up in
> Secure Boot and TPM, which is the wrong place to actually handle this.
> In other operating systems (notably Windows), Secure Boot certificates
> are not used for blocking or enabling kernel-level drivers. Instead,
> there's a kernel-level certificate store that is used to validate and
> enable drivers, allowing everything to be managed in a hardware
> platform agnostic way.

Whether the kernel is installed as an UKI or as a separate kernel+initrd, 
doesn't
change much for driver loading. In SecureBoot mode, the kernel will refuse to
load any module that is not signed. But there is a big difference for userspace
code: with a UKI, the early boot userspace code is also signed and the signature
can be verified like with the kernel. (And once this code has been loaded, and
we have normal userspace, we can do futher verifications on other code that is
loaded later.)

If additional modules need to be loaded from outside of the UKI, this is
entirely doable. Systexts are one solution that is proposed, but it may not be
even be the best fit in this case, because sysexts are designed to extend the
initrd file system with additional code. They are a good solution when for
example you want to add a bluetooth stack to the initrd, but overkill for the
case of a module file. For modules, what we need is a way for the initrd code to
access some additional storage and e.g. try to load all files matching a certain
name pattern

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Neal Gompa

On Wed, Dec 21, 2022 at 12:33 PM Lennart Poettering
 wrote:
>
> On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > And journaling actually is more a problem than a solution due to
> > > firmware (or grub) filesystem drivers often not having full support for
> > > the journal.  Luckily this is rarely a problem in practice because /boot
> > > is rarely written to.
> >
> > We could just make those read-only from the bootloader side then. I
> > have /boot on btrfs, which grub/efifs doesn't support writing to at
> > all anyway. Write grubenv settings into the BIOS boot partition or ESP
> > rather than /boot.
>
> The ESP is more important for booting than /boot. It's a bit weird you
> are fun with writes to the former, but have issues with the latter.
>
> Generally: boot counting/assement/fallback data is best attached to
> the resources it's supposed to cover, to make rotating/vacuuming of
> that data obvious and robust. Otherwise if you remove a boot entry you
> need to find the matching data at a completely different place and
> remove that too, which is quite fragile.
>
> sd-boot implements boot counting by stashing the counter inside the
> UKI (or bootspec type #1 conf file) file name, so that the counter is
> impossible to ever get lost, pile up or so.
>

Because the ESP is intended to be shared, and these days /boot is not.
Unshared boot content should not be in a shared space.

We can only really have one boot manager, especially with how broken
multiple ESPs on a system are.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Neal Gompa

On Wed, Dec 21, 2022 at 12:29 PM Lennart Poettering
 wrote:
>
> On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > > > Why shouldn't FAT be used for /boot.  In an EFI world, /boot
> > > > > is used for the same functional pupose as the ESP, which is
> > > > > already going to use FAT.
> > > >
> > > > Doesn't support links, lournaling and ACLs.
> > >
> > > What you want in a boot loader: native read access, write access.
> >
> > Actually no, I don't want the boot loader / boot manager writing
> > anything.
>
> Well, good for you.
>
> But I think it would be wise for Fedora to implement automatic
> fallback for hosed kernels, and that requires counting boot attempts,
> and that requires storing the counters somewhere. And that means we
> need to store something somewhere. Hence write access from pre-boot is
> typically desirable. Basically, there are too places a boot loader can
> write stuff: file system and NVRAM. The latter is problematic to write to
> since cheap hw supposedly doesn't allow too many write cycles before
> breaking. Hence file system it must be.
>
> If Fedora every intends to be useful for people who cannot recover a
> hosed system on their own because they are Linux guru themselves, I am
> pretty sure we want automatic boot assessment/fallback logic in place.
>
> And similar for server/embedded stuff. If fedora wants to be deployed
> in such worlds, it's kinda nice if we can automatically recover from
> hosed updates.
>

None of those things require us to write data to /boot. Even in your
model, if you *must* write to a filesystem, the counters can live on
the ESP even if all the system-installed content exists in /boot. I'm
sure you could envision a simple file in the ESP for that. None of
that is permanent configuration, just transient stuff.

> I am sure Neal Gompa can recover his own machines, but not every
> Fedora system comes with a Neal Gompa deployment included.
>

Okay, if you're going to be a jerk about it, no Fedora system comes
with a helpful version of Lennart to work out problems people
encounter with this stuff.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote:

> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal.  Luckily this is rarely a problem in practice because /boot
> > is rarely written to.
>
> We could just make those read-only from the bootloader side then. I
> have /boot on btrfs, which grub/efifs doesn't support writing to at
> all anyway. Write grubenv settings into the BIOS boot partition or ESP
> rather than /boot.

The ESP is more important for booting than /boot. It's a bit weird you
are fun with writes to the former, but have issues with the latter.

Generally: boot counting/assement/fallback data is best attached to
the resources it's supposed to cover, to make rotating/vacuuming of
that data obvious and robust. Otherwise if you remove a boot entry you
need to find the matching data at a completely different place and
remove that too, which is quite fragile.

sd-boot implements boot counting by stashing the counter inside the
UKI (or bootspec type #1 conf file) file name, so that the counter is
impossible to ever get lost, pile up or so.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote:

> > > > Why shouldn't FAT be used for /boot.  In an EFI world, /boot
> > > > is used for the same functional pupose as the ESP, which is
> > > > already going to use FAT.
> > >
> > > Doesn't support links, lournaling and ACLs.
> >
> > What you want in a boot loader: native read access, write access.
>
> Actually no, I don't want the boot loader / boot manager writing
> anything.

Well, good for you.

But I think it would be wise for Fedora to implement automatic
fallback for hosed kernels, and that requires counting boot attempts,
and that requires storing the counters somewhere. And that means we
need to store something somewhere. Hence write access from pre-boot is
typically desirable. Basically, there are too places a boot loader can
write stuff: file system and NVRAM. The latter is problematic to write to
since cheap hw supposedly doesn't allow too many write cycles before
breaking. Hence file system it must be.

If Fedora every intends to be useful for people who cannot recover a
hosed system on their own because they are Linux guru themselves, I am
pretty sure we want automatic boot assessment/fallback logic in place.

And similar for server/embedded stuff. If fedora wants to be deployed
in such worlds, it's kinda nice if we can automatically recover from
hosed updates.

I am sure Neal Gompa can recover his own machines, but not every
Fedora system comes with a Neal Gompa deployment included.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Neal Gompa

On Wed, Dec 21, 2022 at 12:15 PM Lennart Poettering
 wrote:
>
> On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org) 
> wrote:
>
> > On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > > Why shouldn't FAT be used for /boot.  In an EFI world, /boot
> > > is used for the same functional pupose as the ESP, which is
> > > already going to use FAT.
> >
> > Doesn't support links, lournaling and ACLs.
>
> What you want in a boot loader: native read access, write access.
>

Actually no, I don't want the boot loader / boot manager writing anything.

> What UEFI doesn't have any understanding of and just ignores: symlinks, ACLs.
>
> What grub's fs drivers doesn't even implement: journalling, write access.
>
> hence, ext4 via efis might be OK as a compat solution, but it delivers
> only stuff one doesn't want, and lacks everything one does want.
>

Sounds great! It means write operations only happen in the OS and
nowhere else. That's what I want.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Demi Marie Obenour

On 12/21/22 12:17, Lennart Poettering wrote:
> On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote:
> 
>>> At least for the systemd stuff, we carefully made sure that our access
>>> patterns to the ESP both from sd-boot/sd-stub and from userspace are
>>> by default as minimal and robust as we can make them, to minimize
>>> chance of corruption, given that vfat is not particularly good with
>>> that. (i.e. we sync a lot, and the whole ESP mount is by default an
>>> autofs instance with an extremely short idle timeout so that it
>>> basically remains unmounted — and thus — clean during almost all
>>> times).
>>>
>>> Anyway, if you want to know more about choice of the fs for /boot/,
>>> see my ideas here:
>>>
>>> https://0pointer.net/blog/linux-boot-partitions.html
>>>
>>> Lennart
>>
>> Does vfat support atomic rename?  Is it possible to atomically upgrade
>> a bootloader/UKI/etc?
> 
> Depends on the fs driver. But yeah, the filename is stored at exactly
> one place, and hence typically a single-sector update is
> possible. (well, within bounds: for example if you rename a file from
> a short filename to a long one, fs driver might need to allocate a
> bunch of separate long file name dir entries, which might then span
> multiple sectors)
> 
> Lennart

Under what circumstances do the Linux kernel driver and the firmware
driver actually make such guarantees?  For instance, is renaming a file
with a longer name to a shorter name (and replacing the old one) atomic?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 14:00, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal.  Luckily this is rarely a problem in practice because /boot
> > is rarely written to.
>
> The journal is very useful when writing kernels there.

how so? iirc grub's fs drivers can't even replay the journal?

if you drop single files into vfat by creating a file under a random
name, then writing the file linearly in full, then syncing, and then
renaming it to the final name (and syncing again) you should get
equal/better guarantees from the fs, in a way actually compatible with
the pre-boot env.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote:

> > At least for the systemd stuff, we carefully made sure that our access
> > patterns to the ESP both from sd-boot/sd-stub and from userspace are
> > by default as minimal and robust as we can make them, to minimize
> > chance of corruption, given that vfat is not particularly good with
> > that. (i.e. we sync a lot, and the whole ESP mount is by default an
> > autofs instance with an extremely short idle timeout so that it
> > basically remains unmounted — and thus — clean during almost all
> > times).
> >
> > Anyway, if you want to know more about choice of the fs for /boot/,
> > see my ideas here:
> >
> > https://0pointer.net/blog/linux-boot-partitions.html
> >
> > Lennart
>
> Does vfat support atomic rename?  Is it possible to atomically upgrade
> a bootloader/UKI/etc?

Depends on the fs driver. But yeah, the filename is stored at exactly
one place, and hence typically a single-sector update is
possible. (well, within bounds: for example if you rename a file from
a short filename to a long one, fs driver might need to allocate a
bunch of separate long file name dir entries, which might then span
multiple sectors)

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > Why shouldn't FAT be used for /boot.  In an EFI world, /boot
> > is used for the same functional pupose as the ESP, which is
> > already going to use FAT.
>
> Doesn't support links, lournaling and ACLs.

What you want in a boot loader: native read access, write access.

What UEFI doesn't have any understanding of and just ignores: symlinks, ACLs.

What grub's fs drivers doesn't even implement: journalling, write access.

hence, ext4 via efis might be OK as a compat solution, but it delivers
only stuff one doesn't want, and lacks everything one does want.

> Everyone can do whatever they want with the files, and a trivial power
> outage can easily wipe out all of its contents.

As mentioned elsewhere, write access to the ESP are generally done at
a very limited set of operations:

1. new kernel installed/old one removed
2. boot loader updates
3. random seed refreshes
4. boot counter updates

All of these are extremely simple operations, that either are single
sector writes, or implemented via whole file replacement, which
typically can be implemented robustly even on vfat. i.e there's no
long-running access, no random access, nothing like that.

systemd's autofs logic for the ESP (and the write patterns bootctl
implements) are designed to give you data safety for the ESP to the
level this could be possible. Sure, it's still no journalling, but
it's as close as it can get.

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Demi Marie Obenour

On 12/21/22 12:00, Lennart Poettering wrote:
> On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
> 
>> For the general case we need some other option.  Could be just stick to
>> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
>> and ppc64le).  Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers,
>> for example this one:
>>   https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg
> 
> I am pretty strongly against the idea of ext4 for /boot/.
> 
> First of all, the firmware can't read it natively, but what's worse,
> uefi cannot even make sense of any of the features it provides above
> vfat. i.e. file ownership, access modes, ACLs, selinux labels, xattrs,
> symlinks, … are all complete nonsense to the UEFI fs layer (and to
> boot loaders that natively implement the fs drivers, the same). The
> UEFI fs API has no concepts for *any* of these features. Hence, if
> this is supposed to carry data intended for consumption by the boot
> loader, why the f**k would you use a file system it cannot even
> remotely take benefit of?
> 
> Also, I am pretty sure boot loaders should have the ability to make
> changes to the file systems they read UKIs from, to implement boot
> counting and random seed management. grub fs drivers and the stuff
> derived thereof (i.e. efifs stuff) typically is read-only though.
> 
> At least for the systemd stuff, we carefully made sure that our access
> patterns to the ESP both from sd-boot/sd-stub and from userspace are
> by default as minimal and robust as we can make them, to minimize
> chance of corruption, given that vfat is not particularly good with
> that. (i.e. we sync a lot, and the whole ESP mount is by default an
> autofs instance with an extremely short idle timeout so that it
> basically remains unmounted — and thus — clean during almost all
> times).
> 
> Anyway, if you want to know more about choice of the fs for /boot/,
> see my ideas here:
> 
> https://0pointer.net/blog/linux-boot-partitions.html
> 
> Lennart

Does vfat support atomic rename?  Is it possible to atomically upgrade
a bootloader/UKI/etc?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Demi Marie Obenour

On 12/20/22 16:34, Simo Sorce wrote:
> On Tue, 2022-12-20 at 14:56 -0500, Demi Marie Obenour wrote:
>> How do you plan to handle system recovery?  For VMs this is much
>> less of a concern, but on bare metal there needs to be a way for
>> a local, authenticated administrator to obtain a root shell on
>> the system console even if the root filesystem cannot be mounted.
>> This has saved my system more than once.
>>
>> Also, how will Xen be supported in this model?  Will the hypervisor
>> be part of an alternate UKI?  CCing Marek Marczykowski-Gorécki of
>> Qubes OS.
> 
> It is all answered in the large amount of text you quoted, if you read
> it carefully.
> The old kernel+inird does not go away, so you disable secure boot and
> just use the good old methods, or worst case you use a recovery disk
> (or USB drive, or whatever you use to install) if you damaged the boot
> partition.
> 
> Anything that is not explicitly supported likewise will use the old
> kernel + custom initrd, you just disable secure boot.

If rescuing a system means disabling secure boot, then there is no point
in having secure boot in the first place, because malware can reliably
cause the user to disable it.  There needs to be a way to rescue the
system *without* disabling secure boot, at least as long as the UKI can
itself be loaded.  Furthermore, this must not require the user to enter
secrets until they have (via TPM PCR-based attestation) verified that
the system is booting trusted code.  This means that the initramfs must
be able to authenticate the user.  And having Xen be incompatible with
secure boot is not something Xen users are going to be happy with,
especially because Xen fully supports UKIs that include the hypervisor.

Having this be out of scope for phase 1 is fine, but it should be
supported eventually.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 06:27, Neal Gompa (ngomp...@gmail.com) wrote:

> On Wed, Dec 21, 2022 at 6:23 AM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 20/12/2022 19:56, Chris Murphy wrote:
> > > Great. The gotcha though is this in effect requires a change in the file 
> > > system currently mounted at /boot, which is ext4. And ext4 isn't 
> > > supported by sd-boot or UEFI firmware. So if you're going to support 
> > > sd-boot, the installer needs to be aware that either the ESP is big 
> > > enough to be used as /boot, or if it's not big enough then it will be 
> > > mounted on /efi*and*  a new partition XBOOTLDR formatted as FAT will be 
> > > used as /boot.
> >
> > Nobody should use FAT for /boot. efifs[1] should be used instead.
> >
> > systemd-boot can load these drivers from ESP out of the box[2].
> >
> > [1]: https://github.com/pbatard/efifs
> > [2]: https://github.com/systemd/systemd/issues/15617
>
> Indeed. We should not endeavor to create more problems by putting more
> stuff in the ESP. By doing so, we lose features and capabilities from
> our own native filesystem. No matter what boot manager we use, we
> should not be required to give that up. We already have efifs[1]
> packaged in Fedora, let's use that.

That's such a weird logic. /boot is supposed to contain data consumed
by the boot loader, not so much by the OS.

What do you think a boot laoder is going to do with access modes, file
ownership, selinux labels?

I am pretty sure we should reduce problems and simplify things by just
using VFAT for boot loader stuff, and put everything at the least
number of places possible.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 12:22, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> On 20/12/2022 19:56, Chris Murphy wrote: > Great. The gotcha though
> is this in effect requires a change in the file system currently
> mounted at /boot, which is ext4. And ext4 isn't supported by sd-boot
> or UEFI firmware. So if you're going to support sd-boot, the
> installer needs to be aware that either the ESP is big enough to be
> used as /boot, or if it's not big enough then it will be mounted on
> /efi*and* a new partition XBOOTLDR formatted as FAT will be used as
> /boot.
>
> Nobody should use FAT for /boot. efifs[1] should be used instead.

I vehemently disagree. VFAT is the way to go. It's simply a pointless
excercise to use anything else.

https://0pointer.net/blog/linux-boot-partitions.html

I think it might be OK to stick to ext4 for upgrades, but outside of
that, for new installs it's something that really should be avoided I
am sure.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:

> For the general case we need some other option.  Could be just stick to
> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
> and ppc64le).  Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers,
> for example this one:
>   https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg

I am pretty strongly against the idea of ext4 for /boot/.

First of all, the firmware can't read it natively, but what's worse,
uefi cannot even make sense of any of the features it provides above
vfat. i.e. file ownership, access modes, ACLs, selinux labels, xattrs,
symlinks, … are all complete nonsense to the UEFI fs layer (and to
boot loaders that natively implement the fs drivers, the same). The
UEFI fs API has no concepts for *any* of these features. Hence, if
this is supposed to carry data intended for consumption by the boot
loader, why the f**k would you use a file system it cannot even
remotely take benefit of?

Also, I am pretty sure boot loaders should have the ability to make
changes to the file systems they read UKIs from, to implement boot
counting and random seed management. grub fs drivers and the stuff
derived thereof (i.e. efifs stuff) typically is read-only though.

At least for the systemd stuff, we carefully made sure that our access
patterns to the ESP both from sd-boot/sd-stub and from userspace are
by default as minimal and robust as we can make them, to minimize
chance of corruption, given that vfat is not particularly good with
that. (i.e. we sync a lot, and the whole ESP mount is by default an
autofs instance with an extremely short idle timeout so that it
basically remains unmounted — and thus — clean during almost all
times).

Anyway, if you want to know more about choice of the fs for /boot/,
see my ideas here:

https://0pointer.net/blog/linux-boot-partitions.html

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mi, 21.12.22 10:16, Chris Adams (li...@cmadams.net) wrote:

> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and remains in unswappable memory
> > - root= syntax is limited to what the kernel understands, i.e.
> >   no root=UUID=… o root=/dev/disk/by-path/… or other udev links,
> >   no encryption or dm-verity.
> > - no bluetooth keyboards or other fancy peripherals
> > - recovery is pretty hard
>
> Also, the security lock-down for the kernel command line means:
> - no network root filesystem
> - no boot-time-only kernel/module configuration
>
> The idea of switching from grub2 to sd-boot would also drop network boot
> and BIOS support.  Supporting boot loaders seems to be a bit of a issue
> sometimes, so trying to support multiple boot loaders seems like a bad
> idea to me.

I am not sure why you think that kernel command line lockdown would mean
no network root fs anymore?

I mean, sure, if you use the Fedora supplied vanilla signed UKI
without anything else then it won't boot from a network, because that
would be a security hole. But I see no reason why a network boot UKI
couldn't be build that maybe be booted via PXE and derives root fs
info from DHCP alone.

(I mean, this is going to be as secure or insecure as your DHCP leases
are protected, but the security is definitely not going to be worse
than in the status quo ante that way)

(you could also build/sign your own UKIs with the network boot info
baked in. Or you could use TPM-bound systemd "credentials" to provide
the network server info to the booted kernel securely)

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Daniel P . Berrangé

On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and remains in unswappable memory
> > - root= syntax is limited to what the kernel understands, i.e.
> >   no root=UUID=… o root=/dev/disk/by-path/… or other udev links,
> >   no encryption or dm-verity.
> > - no bluetooth keyboards or other fancy peripherals
> > - recovery is pretty hard
> 
> Also, the security lock-down for the kernel command line means:
> - no network root filesystem
> - no boot-time-only kernel/module configuration
> 
> The idea of switching from grub2 to sd-boot would also drop network boot
> and BIOS support.  Supporting boot loaders seems to be a bit of a issue
> sometimes, so trying to support multiple boot loaders seems like a bad
> idea to me.

I certainly wouldn't suggest supporting multiple boot loaders with the
complexity level of grub.  sd-boot is quite a different beast though.
It is drastically limited in scope/features, with the actual loading
process offloaded to UEFI services, so probably better thought of as
merely a boot menu. It can't replace grub given its limited scope,
but it is not unreasonable to consider supporting it in parallel for
the cases where the kitchen sink is not required, since it makes it
massively easier to predict TPM measurements than grub.

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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Di, 20.12.22 13:56, Chris Murphy (li...@colorremedies.com) wrote:

> > * Better secure boot support (specifically the initrd is covered by
> > the signature).
>
> We need to solve the glaring hole that is the initrd. There's no
> question about it. I can't really assess if this feature is the best
> way to do that. Or if it would be adequate for dracut to self-sign
> every locally generated initrd with a unique key pair and throw away
> the private key after each initrd is generated.  Or if we could do
> enough strict standardization in the boot chain with a possibly
> larger kernel to avoid needing an initrd, i.e. get to sysroot mount
> faster thereby obviating the need for a large initrd.

Systems without initrd are unrealistic outside of corner cases. I am
pretty sure that if you care about SecureBoot then you must care about
protecting the root fs somehow, too. Otherwise fixing the initrd hole
is a pretty pointless excercise. Protecting the root fs means
encryption/LUKS, Verity or dm-integrity in some way. But that implies
an initrd, in particular if you want to hook that up with TPM or FIDO2
or so, which I am pretty sure should be considered a pretty common
case sooner or later.

I think initrd-less systems only make sense as a corner case for
certain low-security systems, but certainly not as a default.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

2022-12-21 Thread Tomasz Torcz

On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and remains in unswappable memory
> > - root= syntax is limited to what the kernel understands, i.e.
> >   no root=UUID=… o root=/dev/disk/by-path/… or other udev links,
> >   no encryption or dm-verity.
> > - no bluetooth keyboards or other fancy peripherals
> > - recovery is pretty hard
> 
> Also, the security lock-down for the kernel command line means:
> - no network root filesystem
> - no boot-time-only kernel/module configuration
> 
> The idea of switching from grub2 to sd-boot would also drop network boot
> and BIOS support.  Supporting boot loaders seems to be a bit of a issue
> sometimes, so trying to support multiple boot loaders seems like a bad
> idea to me.

  I'm using network boot without grub2, just iPXE and kernel+initrd.
It worth noting that NFS root doesn't work with dracut from rawhide,
for months now.

-- 
Tomasz Torcz “God, root, what's the difference?”
to...@pipebreaker.pl   “God is more forgiving.”
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)