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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux