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.
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.
* 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
> 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.
_______________________________________________
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
