On Thu, Jul 2, 2020 at 9:49 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote:
>
> On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> >
> > On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> > <johannbg@xxxxxxxxx> wrote:
> > >
> > > On 1.7.2020 16:10, Solomon Peachy wrote:
> > > > On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> > > >> I'm currently using BIOS, grub, grub2 basically everywhere, even on
> > > >> fresh new machines,
> > > > This won't be the case for much longer; Intel will finally drop CSM
> > > > ("BIOS") support this year.
> > > >
> > > > Even putting that aside, for the past several years CSM/BIOS has been
> > > > slowly bitrotting due to a lack of real testing, as the last few Windows
> > > > releases have mandated use of UEFI for preinstalled systems, plus the
> > > > EOLing of Windows 7 and (especially) XP.
> > >
> > > AMD is "strongly" recommending UEFI for the windows [1]
> > >
> > > So Apple dropped CSM in 2006
> > >
> > > Intel in 2020
> > >
> > > AMD is against it's use
> > >
> > > Windows has moved on with the curve...
> > >
> >
> > That's great and all, but of all the cloud providers, only Microsoft's
> > Azure / Hyper-V platform actually requires UEFI support. Nobody else
> > even supports it! Okay, AWS only supports it for AArch64, but not x86.
>
> Google Compute does as well I believe.
>
> > KVM guys here are still recommending BIOS.
> >
> > We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> > kernel configuration is too strict for that. I personally consider it
> > a good thing, but that's a problem for others.
>
> I believe you need to disable secure-boot and it should work, I don't
> believe the issue is actual UEFI in this case, of course BIOS boot
> doesn't have any form of boot security.
>
> > Fix all the other problems we have with UEFI environments before
> > suggesting we drop "legacy BIOS".
>
> That's a very grand sweeping gesture with no details, I suspect most
> of the "problems" (what ever that means) are shity firmware
> implementations of the UEFI spec, we use to have that with BIOS all
> the time too, I suspect the reason we have it less so is that all the
> vendors have long left that code well alone and are only "enhancing"
> UEFI
>
> > It's absolutely shameful that despite us being first to the UEFI
> > Secure Boot support, we *still* can't get things working fully in that
> > environment. And frankly, from what I can tell from all the people
> > involved: nobody cares except for the couple of people who ask every
> > few months why we can't have the NVIDIA driver signed and auto-trusted
> > so it works. I know every time I ask, people respond with "it's not
> > that simple" and more mumbles of Koji architecture problems.
>
> Is that a Fedora specific problem? Are other distros allowing the
> loading of unsigned kernel modules to work around the problem while
> potentially compromising user's security? I feel this is a Linux wide
> issue with a single vendor, and not specific to Fedora at all.
>
It is Fedora-specific. Neither Ubuntu nor openSUSE mandate that all
kmods need to be signed to load. They *warn* on it, but they don't
*block*.
Even with that, openSUSE makes it easy for kernel module packages to
include signed kernel modules. I think openSUSE will eventually switch
to blocking because the reason for not doing it doesn't apply these
days.
> Well there's lots of "reasons" I can think of but experience in the
> Fedora community and my experience in IoT fields and related security
> over the last few years the big ones IMO tend to be:
> * A lot of people would be opposed to Fedora keys signing closed
> source binary drivers, community, Red Hatters, probably legal (but I'm
> not legal) and it may even affect the ability to sign shim and hence
> use secure-boot at all (I've zero insight into this as I'm to lazy too
> even begin to look for how I'd do that) to name but a few.
This is false. The openSUSE builds of the nvidia driver are
auto-signed properly too, because their build system actually
*supports* signing kernel modules.
Use a secondary key instead of the primary one if you want. If I
remember correctly, that's what openSUSE does.
> * Nvidia could sign their binary kernel modules, and the public key
> could be enrolled into the kernel using mokutil likely even
> automatically using some hook, the user would get a prompt each boot
> with a new kernel but it wouldn't be a completely terrible experience.
> You'd have to ask nvidia why this isn't possible
>
They *do* sign it. Their installer actually autogenerates the cert,
signs the kernel modules, and enrolls the cert for you.
So our experience is strictly *worse* than nvidia's.
> > At this point, I personally don't want to see this proposal *ever*
> > come up again unless somebody cares about fixing the user experience
> > with UEFI.
>
> I think you're being very harsh and short sighted here TBH, like
> things like AVX2 it's useful to have these conversations in a civil
> manner, even if the original proposal was short sighted and missed a
> lot of details and won't happen for years to come.
>
> When aarch64 came along I made the decision that the only way Fedora
> would ever support SBCs (like the Pine64, 96boards 410c the first
> early boards we supported) was to use UEFI, and one of the SUSE people
> agreed, most of the rest of the distros followed along. It makes
> things a *LOT* easier for support because we have *one* boot option,
> *one* installer path in anaconda so on and so forth. We could have
> bodged up extlinux support like armv7 uses, and I got a lot of
> pressure to do that. The little extra time it took has overwhelmingly
> worth while and actually changed, and continues to, the arm eco-system
> (watch the Fedora Arm space over the the next 6+ months for even more
> examples of this).
>
> From a Fedora IoT PoV we only support UEFI on any arch we support, the
> reason for that is functionality IoT requires to be actually useful in
> the field, and for security. While I believe BIOS boot works on x86_64
> it's AFAICT it's purely by chance and I won't say this won't break in
> the future if we needed to ensure the OS can remain secure. IoT is
> lucky in that, like aarch64, we're quite new and don't have "legacy"
> users, we may have users that are playing with IoT on legacy HW but I
> don't know and all the users/customers/partners I'm speaking with are
> using UEFI.
I feel like I wasn't harsh enough when this stuff first landed years
ago. I didn't say anything then because I hoped that it would mean
we'd be able to push more drivers into the kernel. Obviously that was
a failure.
Heck, we now have tacit support for non-free kernel module drivers by
all the commercial Linux companies. Oh well.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
