On Thu, Jul 2, 2020 at 9:49 AM Peter Robinson pbrobinson@gmail.com wrote:
On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson johannbg@gmail.com 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!