Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 7, 2021 at 8:23 AM Vitaly Zaitsev via devel wrote: > > On 06/07/2021 23:27, Christian Stadelmann wrote: > > In other words: I think it is too early to drop non-(U)EFI BIOS support. > > Btw, the upcoming Windows 11 will require full UEFI support, enabled > UEFI Secure Boot and TPM 2.0. That is slightly more complicated in later updates by Microsoft, which talks about new computers to be sold retail and installed with Windows (and Microsoft has been upping the requirements for new retail computers slowly over time). They also talk about needing an Intel gen8 processor or better (although that is at least partially likely to be the case because Intel no longer supports older processors according to their support list). For existing devices to upgrade, TPM 1.2 is apparently sufficient, and it is not clear that UEFI (at all, or in Secure Boot mode) will be required, and they do say that older processors are likely to work, but they are not testing them. And it is possible for upgrades from W10 they might relax any or all of the initially stated requirements. For the early adopter builds that have been made available it seems none of the requirements are currently hard (just "recommendations"). So I am not sure that Microsoft's announcements, which seem to be somewhat fluid, should drive Fedora's decisions. Personally, if DUET (or equivalent) worked (and I have not tried it) that would work for me with my few remaining legacy BIOS only boxes; ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On 06/07/2021 23:27, Christian Stadelmann wrote: In other words: I think it is too early to drop non-(U)EFI BIOS support. Btw, the upcoming Windows 11 will require full UEFI support, enabled UEFI Secure Boot and TPM 2.0. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On Tue, Jul 6, 2021 at 7:05 PM Chris Murphy wrote: > > On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann > wrote: > > > > > […] and move to uefi only supported boot which > > > has been available on any common intel based x86 platform since atleast > > > 2005. > > > > (U)EFI was not available for the general market in 2005 (except on Apple > > devices maybe). It was introduced around 2011. > > UEFI support was introduced in Windows Vista, 2007. And it was refined > in Windows 7, 2009. Discussion of UEFI Secure Boot began in earnest in > the Linux world around 2012. And became a requirement for all new > consumer PC's wanting Windows 10 hardware certification, in 2015. > Server hardware has had more leeway. > > > I own 2 devices which are booting with non-(U)EFI BIOS. One is too old, > > manufactured around 2010 when (U)EFI was not available. One is new enough > > to having (U)EFI, but it's a mess and never worked with Fedora's (U)EFI > > integration so I was forced to install it in legacy BIOS mode. > > > > In other words: I think it is too early to drop non-(U)EFI BIOS support. > > I think there probably are too many legacy BIOS systems for us to drop > legacy support in the near term. > > We might consider: > > (a) Revisiting GPT by default. By revisiting that means exploring the > bugs and work arounds. The reason for this is moving toward a > self-describing boot process, and abstracting the low level bootloader > requirements from user space configuration. There's good reasons to > get the user space configuration with Boot Loader Spec support > sufficiently abstracted that we could do a drop in bootloader swap one > day, either for use case specific reasons, or distro wide. > > It could be that we can abandon hardware that can't tolerate GPT, if > the benefits outweigh the consequences. > > (b) Consider DUET as a way to bring UEFI support to BIOS systems. I'm > not sure about the status of this work though, and if it's intended to > bring legacy BIOS systems forward with a single UEFI approach in a > distribution. Or if the intent was only for development purposes until > native UEFI implementations became more ubiquitous. Would adding this > kind of layer just be asking for more things to maintain, > troubleshoot, test, and break? > https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg > DUET would probably be the best shot, but it was removed at the end of 2018 due to the lack of interest and usage[1]. If someone wants to step up to maintain the DuetPkg module for EDK2, we could start going down the path of streamlining the boot process in the same way that has occurred in ARM[2]. We'd also benefit from a relatively consistent UEFI implementation as EDK2 is built on TianoCore[3], which is also where OVMF/AVMF used for UEFI on KVM is from. [1]: https://bugzilla.tianocore.org/show_bug.cgi?id=1322 [2]: https://fedoraproject.org/wiki/Changes/ARMv7UEFI [3]: https://www.tianocore.org/ -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann wrote: > > > […] and move to uefi only supported boot which > > has been available on any common intel based x86 platform since atleast > > 2005. > > (U)EFI was not available for the general market in 2005 (except on Apple > devices maybe). It was introduced around 2011. UEFI support was introduced in Windows Vista, 2007. And it was refined in Windows 7, 2009. Discussion of UEFI Secure Boot began in earnest in the Linux world around 2012. And became a requirement for all new consumer PC's wanting Windows 10 hardware certification, in 2015. Server hardware has had more leeway. > I own 2 devices which are booting with non-(U)EFI BIOS. One is too old, > manufactured around 2010 when (U)EFI was not available. One is new enough to > having (U)EFI, but it's a mess and never worked with Fedora's (U)EFI > integration so I was forced to install it in legacy BIOS mode. > > In other words: I think it is too early to drop non-(U)EFI BIOS support. I think there probably are too many legacy BIOS systems for us to drop legacy support in the near term. We might consider: (a) Revisiting GPT by default. By revisiting that means exploring the bugs and work arounds. The reason for this is moving toward a self-describing boot process, and abstracting the low level bootloader requirements from user space configuration. There's good reasons to get the user space configuration with Boot Loader Spec support sufficiently abstracted that we could do a drop in bootloader swap one day, either for use case specific reasons, or distro wide. It could be that we can abandon hardware that can't tolerate GPT, if the benefits outweigh the consequences. (b) Consider DUET as a way to bring UEFI support to BIOS systems. I'm not sure about the status of this work though, and if it's intended to bring legacy BIOS systems forward with a single UEFI approach in a distribution. Or if the intent was only for development purposes until native UEFI implementations became more ubiquitous. Would adding this kind of layer just be asking for more things to maintain, troubleshoot, test, and break? https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
> […] and move to uefi only supported boot which > has been available on any common intel based x86 platform since atleast > 2005. (U)EFI was not available for the general market in 2005 (except on Apple devices maybe). It was introduced around 2011. I own 2 devices which are booting with non-(U)EFI BIOS. One is too old, manufactured around 2010 when (U)EFI was not available. One is new enough to having (U)EFI, but it's a mess and never worked with Fedora's (U)EFI integration so I was forced to install it in legacy BIOS mode. In other words: I think it is too early to drop non-(U)EFI BIOS support. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 01, 2020 at 12:49:17AM +0200, Kevin Kofler wrote: > Jóhann B. Guðmundsson wrote: > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes > > it beg the question if now would not be the time to stop supporting > > booting in legacy bios mode and move to uefi only supported boot which > > has been available on any common intel based x86 platform since atleast > > 2005. > > No, it would not. > > It would mean desupporting a wide range of existing hardware and some VM > environments (even with QEMU/KVM, I found the SeaBIOS legacy BIOS to be much > less quirky than the OVMF UEFI implementation, and other VM environments > might not support UEFI at all, including older QEMU versions that may still > be in use as hosts for modern Fedora guests). And for what gain? Also SeaBIOS boot is much faster than OVMF, and that matters in many cases (libguestfs for one). Rich. > I do not think switching from GRUB-EFI to systemd-boot as you propose would > be of any benefit for UEFI users. (It would actually mean fewer features for > no tangible benefit.) Hence, we are dealing with GRUB in both enviroments. > So I do not see the maintenance burden of continued BIOS support, also > considering that, in my experience, the environment that keeps causing > problems is actually UEFI, not BIOS. > > > This post is just to gather feed back why Fedora should still continue > > to support legacy BIOS boot as opposed to stop supporting it and > > potentially drop grub2 and use sd-boot instead. > > Fedora should still continue to support legacy BIOS boot. > > Kevin Kofler > ___ > 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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T6CKCW64YVWM6LEPO6KDCTZJYSQVUQL4/ The fact of the rejection of the OP to drop BIOS support is difficult to find. You should therefore have suggested to never again bring up the issue of dropping BIOS support before the year 2030. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4GFKE56HTECMQ45RMPALBDFPMORQCQKQ/ it came up on ask.fedora and is linked into here. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On 2021-05-27 2:28 p.m., Sam Varshavchik wrote: It a shame if Fedora were to abandon its long-time users. This proposal was already brough up earlier this year and was described as a non-starter back then. I haven't paid attention and I hope this is still a non-starter; otherwise, as I said, it will be a shame. This is the same thread. Someone unfortunately re-activated it... ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
Marius Schwarz writes: Am 30.06.20 um 15:34 schrieb Jóhann B. Guðmundsson: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. Now in 2017 Intel's technical marketing engineer Brian Richardson revealed in a presentation that the company will require UEFI Class 3 and above as in it would remove legacy BIOS support from its client and datacenter platforms by 2020 and one might expect AMD to follow Intel in this regard. This will fail i.e. on M$ Surface Pro * systems. Also, a lot of laptops are installed in Legacy Mode, as setting them up in EFI was impossible. I have two servers that predate 2005. They've been running Fedora just fine since then, with no problems whatsoever. Back then, server-level hardware was built to last. I know that at least one of them does not support EFI. It a shame if Fedora were to abandon its long-time users. This proposal was already brough up earlier this year and was described as a non-starter back then. I haven't paid attention and I hope this is still a non-starter; otherwise, as I said, it will be a shame. pgpYYqMjShRjV.pgp Description: PGP signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On Thu, 2021-05-27 at 09:35 +, eedio wrote:
> well,
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/
>
> suggesting to drop BIOS is a nonstarter.
This thread died over half a year ago (back in October of last year)
after the proposal was comprehensively rejected. No-one is currently
proposing to remove it. The thread was inexplicably necro'ed yesterday
by a person I don't recall ever hearing from before ("L Five") purely
to lob some gratuitous personal attacks. I recommend letting it die
again.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On 5/27/21 10:45 AM, Nikolay Nikolov wrote: That is quite a painful process. And how do you do that on a MBR system that dual boots Fedora and Windows 10? I really don't want to go through the pain of reinstalling Windows and all the programs that I have there. There's no migration path that doesn't have some (eventual) pain. And that includes not migrating. A useful place to start is a thorough read of https://opensource.com/article/19/5/dual-booting-windows-linux-uefi https://www.maketecheasier.com/convert-legacy-bios-uefi-windows10/ , considering what exactly your system supports (gpt, efi, etc.), and identifying where you want to end up. I don't migrate hardware until it's demonstrated to make technical & business sense. We've *lots* of legacy-bios/MBR hardware that's perfectly serviceable with either/both modern linux / windows. "It's bright & shiny" isn't a valid argument for change here. Any _software_ that forces unnecessary cost on the ecosystem, including dropping BIOS support or generally breaking stable user-space, will get removed from the picture. Or, at least, _very_ marginalized/compartmentalized. Personally I'm banking on the 'old, wise hats' @ distro here to prevent making foolish choices. So far, so good. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On 5/27/21 5:25 PM, Vitaly Zaitsev via devel wrote: On 27.05.2021 16:17, Marius Schwarz wrote: Also, a lot of laptops are installed in Legacy Mode, as setting them up in EFI was impossible. 1. Backup all data. 2. Convert MBR to GPT. 3. Create an ESP partition, add it to the /etc/fstab file and mount. 4. sudo dnf swap grub2 grub2-efi 5. sudo dnf install shim (only if needed). 6. Reboot. That is quite a painful process. And how do you do that on a MBR system that dual boots Fedora and Windows 10? I really don't want to go through the pain of reinstalling Windows and all the programs that I have there. Nikolay ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On 27.05.2021 16:17, Marius Schwarz wrote: Also, a lot of laptops are installed in Legacy Mode, as setting them up in EFI was impossible. 1. Backup all data. 2. Convert MBR to GPT. 3. Create an ESP partition, add it to the /etc/fstab file and mount. 4. sudo dnf swap grub2 grub2-efi 5. sudo dnf install shim (only if needed). 6. Reboot. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
Am 30.06.20 um 15:34 schrieb Jóhann B. Guðmundsson: Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. Now in 2017 Intel's technical marketing engineer Brian Richardson revealed in a presentation that the company will require UEFI Class 3 and above as in it would remove legacy BIOS support from its client and datacenter platforms by 2020 and one might expect AMD to follow Intel in this regard. This will fail i.e. on M$ Surface Pro * systems. Also, a lot of laptops are installed in Legacy Mode, as setting them up in EFI was impossible. best regards, Marius Schwarz ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
well, https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ suggesting to drop BIOS is a nonstarter. much like Mr Jóhann B. Guðmundsson's argument that UEFI is on sale since 2005 , only 16 years. A completely weightless argument since only this counts: How many users does BIOS have today ? And that number is huge. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
> On Saturday, July 4, 2020 6:44:55 AM MST Solomon Peachy wrote: > > There are still new systems built today that only support BIOS, and vendors > providing systems factory-configured for BIOS boot on hardware that does > support UEFI. There is no 2TB upper limit on drive sizes as a result of > booting from BIOS. > > > > I don't know where you got this, but that's completely false. You can use GPT > partition tables on systems with BIOS boot. Whoever told you otherwise is > misinformed at best. > > > Why do you "despise" BIOS boot? > > > I highly doubt that, but time will tell. > > > That's absolutely false, as demonstrated elsewhere in this thread. Pretending > otherwise is delusional, and delusions are no basis for technical decisions. As Mr Poettering noted earlier and quite correctly, JMH junior ought to grow up. Harris junior is not to be taken seriously. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
b On Tue, Oct 20, 2020 at 8:49 PM Jóhann B. Guðmundsson wrote: > > On 19.10.2020 17:25, Michael Catanzaro wrote: > > On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis > > wrote: > >> I'am also have Thikpads and MSI running BIOS and some of those > >> machines still are the beast in some terms. Dropping BIOS would > >> pretty much force me to use something else. > >> I don't want to lose Fedora. > > > > This proposal was soundly rejected, so don't worry about it. > > > Never was an official proposal to begin with so I cant see how it was > "soundly rejected" but yes the dialog highlighted that there will be > quite few years before the distribution can get to the point where an > official proposal can be made. Maybe 2024 would be a target goal for > such effort. Regardless consensus has to be reached on how long/old > hardware should be supported so people expectations can be > raised/lowered accordingly. Arguably something that the Council should > look at. While I don't actually believe old hardware should be dropped I don't believe there was a consensus reached. Fedora is a distribution that aims to be first so I believe there should be work done so that spins or editions that wish to be able to drop support for BIOS installs while other parts of the distribution retaining compatibility for legacy platforms be enable to do so and I don't feel that that discussion has been had, a lot of the discussion was focused on single people "this is my use case" not the wider use cases of the distribution or what SIGs are interested in. ___ 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
Re: The future of legacy BIOS support in Fedora.
On 19.10.2020 17:25, Michael Catanzaro wrote: On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis wrote: I'am also have Thikpads and MSI running BIOS and some of those machines still are the beast in some terms. Dropping BIOS would pretty much force me to use something else. I don't want to lose Fedora. This proposal was soundly rejected, so don't worry about it. Never was an official proposal to begin with so I cant see how it was "soundly rejected" but yes the dialog highlighted that there will be quite few years before the distribution can get to the point where an official proposal can be made. Maybe 2024 would be a target goal for such effort. Regardless consensus has to be reached on how long/old hardware should be supported so people expectations can be raised/lowered accordingly. Arguably something that the Council should look at. 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
Re: The future of legacy BIOS support in Fedora.
Le mardi 20 octobre 2020 à 12:32 +0200, Petr Pisar a écrit : > > In my opinion what became slugish (besides web browsers) are desktop > environments that "accelerated" GUI by a move to OpenGL and > JavaScript. > A typical examples are login managers. GDM actually loads full Gnome, > thus GDM > consumes 500 MB of memory and after logging in Gnome shell for user's > session > takes another 500 MB. SDDM becomes insanely graphics-demanding. The > QML > backend first started polling old Intel VGAs, then spits flickering > artifacts > on old Radeons. Regarding feature-parity it completely looses to KDM > (no XDM, > broken PAM with non-password authentication mechisms, it even became > a blocker > for F33). The worst thing is that was done as the same time that wayland moved input management to the window manager. Any random GUI action can now result in feel-good GUI prettification that will starve input processing of CPU, resulting in frozen mouse pointers and missed repeated or reordered keystrokes. So, useless desktop except as a browser shell where typing is marginal. > journalctl | grep gnome-shell | grep 'libinput error' | grep 'your system is too slow' | wc -l 7060 > cat /proc/cpuinfo | grep model model : 142 model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz model : 142 model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz model : 142 model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz model : 142 model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz Hardly an underpowered system -- Nicolas Mailhot ___ 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
Re: The future of legacy BIOS support in Fedora.
On 10/19/20 6:47 PM, Stephen John Smoogen wrote: The issue is that while 'moore's' law was no longer doubling every 18months it was still working and tasks had to be rewritten to work with more cores/threads/etc. As that happened the software's need for more CPU power has increased to the point were a 10+ year computer isn't very useful for 'modern' software (browser and various applications). Instead if you want to have something work on a 2012 system well.. just use software from 2012. It is still available. I know you know, you are being polemic and cheating. 2012's SW is unusable today. Sure you can install Linux on that 15 year old computer but if you have to tell the user well you can't actually use a browser, an editor or half the things you can do on your cheapest smart-phone.. what use is that computer? Do yourselves a favor and try it yourselves: A 2012 mid-class system still outperforms many todays low-end systems and many notebooks. These systems are well suitable for many purposes! Ralf ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 12:47:55PM -0400, Stephen John Smoogen wrote: > > The issue is that while 'moore's' law was no longer doubling every 18months > it was still working and tasks had to be rewritten to work with more > cores/threads/etc. As that happened the software's need for more CPU power > has increased to the point were a 10+ year computer isn't very useful for > 'modern' software (browser and various applications). I'm curious what are the various applications. Web browsers gained multi-threading because they expelled plugins and started bundling everything what used to be part of a desktop (namely processing audio and video). As far as I know JavaScript environment is still single-threaded. Video players can offload decoding to graphics cards if needed. (Although in my part of world a 10-year-old CPU is enough because you rarely get something more demanding than 720p H.264.) In my opinion what became slugish (besides web browsers) are desktop environments that "accelerated" GUI by a move to OpenGL and JavaScript. A typical examples are login managers. GDM actually loads full Gnome, thus GDM consumes 500 MB of memory and after logging in Gnome shell for user's session takes another 500 MB. SDDM becomes insanely graphics-demanding. The QML backend first started polling old Intel VGAs, then spits flickering artifacts on old Radeons. Regarding feature-parity it completely looses to KDM (no XDM, broken PAM with non-password authentication mechisms, it even became a blocker for F33). > Instead if you want to have something work on a 2012 system well.. just use > software from 2012. With security bugs from 2012. No thanks. -- Petr signature.asc Description: PGP signature ___ 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
Re: The future of legacy BIOS support in Fedora.
Am 19.10.20 um 18:47 schrieb Stephen John Smoogen: > The issue is that while 'moore's' law was no longer doubling every > 18months it was still working and tasks had to be rewritten to work > with more cores/threads/etc. As that happened the software's need for > more CPU power has increased to the point were a 10+ year computer > isn't very useful for 'modern' software (browser and various > applications). Instead if you want to have something work on a 2012 > system well.. just use software from 2012. It is still available. > Sure you can install Linux on that 15 year old computer but if you > have to tell the user well you can't actually use a browser, an editor > or half the things you can do on your cheapest smart-phone.. what use > is that computer? > Sorry to interrupt, but thats not true. ATM i have a 2013 System running and it's same as fast as it was 2013. No Firefox update changed that nor did it stop me from running games on 100 FPS+ on FHD (FX8350/16GBRAM). If you had made a choice for "invest more, keep it longer" in 2013, it still runs smooth. I even had a friend mentioning his >11y old (now) Win10 pc still running fine, and you know how much windows bloated in this time. But if you bought your PC in 2013 with 2 Intel Mobile Cores and 2 GB RAM than it's your poor choice of hw in 2013 thats limiting you now. The times, when PC hw is obsoleted 5 years later, are over for the common users. What do they do? Watch Netflix, read mail, print picture. You simply don't need a 48 Core cpu for this. In this spirit: Dropping legacy bios support is a mistake. best regards, Marius ___ 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
Re: The future of legacy BIOS support in Fedora.
Le lundi 19 octobre 2020 à 12:47 -0400, Stephen John Smoogen a écrit : > It is only after Moore's law 'broke' after 2003 stopped seeing > doubling cpu speeds every 18 months that trying to keep hardware > useful longer than 5 years has been possible. The real turning point is when Microsoft missed its 64bit conversion. Previously, you could always add a couple of years of useful lifetime to a computer just by adding some memory (because memory is one of the key parameters manufacturers skimp on). But, once most of the market got stuck in 4GiB land due to Windows limitations, you could suddenly add a decade or so of lifetime just by using the fact Linux was 64 bit to grossly outscale the default Windows-oriented memory setup. Now the gap is slowly shrinking now that Windows is 64bit and manufacturers learn to use memory again. But it will be some time before the 64bit-ed Linux installed base get outperformed enough to be retired Regards, -- Nicolas Mailhot ___ 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
Re: The future of legacy BIOS support in Fedora.
Arnoldas Skinderis writes: I'am also have Thikpads and MSI running BIOS and some of those machines still are the beast in some terms. Dropping BIOS would pretty much force me to use something else. I don't want to lose Fedora. Ditto. My Thinkpad W520 is the best damn Fedora laptop. Ever. I have two newer laptops, they run Fedora just fine, but the legendary Thinkpad keyboard is generations ahead of the crappy chiclets on the other one. Laughably easy to maintain. In the ten or so years I had it, I only had to replace that keyboard once, that's it. Oh, and put a new touchpad sticker, to replace the worn-out membrane cover. This beast, as long as it can still run Fedora, will likely outlive me, and I'll have to will it to someone… pgpXQY6J1Akw_.pgp Description: PGP signature ___ 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
Re: The future of legacy BIOS support in Fedora.
On 10/19/20 11:33 AM, Hans de Goede wrote: I guess those machines are more or less the cut-off point and slower machines are not worth keeping around. But that means that there still are a ton of BIOS machines worth keeping around. Note that even most sandy bridge machines do not support UEFI and those machines are still very capable. I've got ~30 non-EFI Acer TimelineX Aspire 3820Ts, circa ~ 2009-10 still in 'production' across the enterprise. e.g., dmesg | grep DMI: [0.00] DMI: Acer Aspire 3820/JM31_CP, BIOS V1.19 10/27/2010 They currently run (recently migrated) grep _NAME /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" CPE_NAME="cpe:/o:fedoraproject:fedora:32" uname -rm 5.8.15-201.fc32.x86_64 x86_64 **ALL* have cat /proc/cpuinfo |grep "^model name" model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz , 8GB RAM free totalusedfree shared buff/cache available Mem:7806944 673488 3105532 102896 4027924 6733392 Swap: 8388604 0 8388604 , 500GB ssds, hwinfo --disk | grep Device: Device: "CT1000MX500SSD1" and run libreoffice-x11-6.4.7.2-1.fc32.x86_64 VirtualBox-6.1-6.1.14_140239_fedora32-1.x86_64 (Win10 guests) Firefox 81.0.2 Thunderbird 78.3.3 as well as java --version openjdk 15 2020-09-15 OpenJDK Runtime Environment 20.9 (build 15+36) OpenJDK 64-Bit Server VM 20.9 (build 15+36, mixed mode, sharing) a number run PhpStorm 2020.3 EAP Build #PS-203.4818.52, built on October 15, 2020 &/or Eclipse Platform Version: 2020-03 (4.15) Build id: I20200305-0155 My own manages nginx/php & mariadb quite nicely as well. Are these screamin' fast? Do they have 8K screens to play video games on? No. Of course not. But they are *perfectly* serviceable/functional; and that's just one model of 'oldies' around here. All that^ is _still_ more 'juice' than many a VPS ... what it requires to make old boxes 'serve well' is some due diligence on right-sizing your kernel/app/server/tool/etc configs. AND a distro (even if it's a DIY LFS ...) that makes it possible. It really just is way too early / too soon to cut of BIOS booting support. big emphasis on the 'way'. i for one am certainly glad that that's the decision that's been taken, and that i won't have to face migrating to yet-another-OS because of bad enterprise policy decisions. esp, since Fedora's grown on me ... ___ 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
Re: The future of legacy BIOS support in Fedora.
Hi, On 10/19/20 6:47 PM, Stephen John Smoogen wrote: > The issue is that while 'moore's' law was no longer doubling every 18months > it was still working and tasks had to be rewritten to work with more > cores/threads/etc. As that happened the software's need for more CPU power > has increased to the point were a 10+ year computer isn't very useful for > 'modern' software (browser and various applications). Instead if you want to > have something work on a 2012 system well.. just use software from 2012. It > is still available. Sure you can install Linux on that 15 year old computer > but if you have to tell the user well you can't actually use a browser, an > editor or half the things you can do on your cheapest smart-phone.. what use > is that computer? My daughter actually took a 12+ years old (one of the first 64 bit core 2 duo models) laptop (Dell Latitude E6400) with her to school for a project last week and happily ran a browser (latest firefox) and libreoffice on it without issues. Sure I've probably upgraded the RAM a bit at some point (I don't remember when I did that, so a long time ago) and I dropped in a SSD something like 5 years ago I guess. But with those 2 upgrades it still is a fine machine for a lot of things. And the PC in the living room used for netflix, disney+ and primevideo is another core 2 duo (one of the later gens) models happily doing what we ask of it; and my wife's home-office machine is another ... I guess those machines are more or less the cut-off point and slower machines are not worth keeping around. But that means that there still are a ton of BIOS machines worth keeping around. Note that even most sandy bridge machines do not support UEFI and those machines are still very capable. It really just is way too early / too soon to cut of BIOS booting support. Regards, Hans ___ 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
Re: The future of legacy BIOS support in Fedora.
> >> This proposal was soundly rejected, so don't worry about it. > > > > That's great news. Thank you! > I am not thrilled that this has been rejected since efi support is not > so good on Fedora. How do you mean, it's supported quite well IMO with support for things like secure boot and UEFI capsule updates for updating system firmware I feel it's in quite good state with people improving on things constantly. > Devices that are BIOS can IIRC still use efi using a boot tool > installed to the MBR which emulates EFI > and than loads the EFI loader. This would be a one time step. Why bother, just adds an extra layer of complexity with no added benefits that UEFI provides. > Hopefully Fedora will have enough resources to support systemd-boot on > Fedora Silverblue, > which has never worked so far due to ostree naming conventions I see that less likely because of the need to have a already stretched team supporting yet another boot path. > https://github.com/ostreedev/ostree/issues/1951 > ___ > 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 ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 5:46 PM Damian Ivanov wrote: > > >> This proposal was soundly rejected, so don't worry about it. > > > > That's great news. Thank you! > I am not thrilled that this has been rejected since efi support is not > so good on Fedora. > Devices that are BIOS can IIRC still use efi using a boot tool > installed to the MBR which emulates EFI > and than loads the EFI loader. This would be a one time step. I believe EFI emulation would be too big to fit in the 446 bytes available in the MBR, so one would need a biosboot partition for that EFI emulator, but the other issue (as I recall) was that the EFI emulation had been using IP that may not be appropriately "free" (fat32?). Perhaps now that that IP has been contributed to OIN (and the various legal reviews and processes for Fedora to properly utilize those patents are complete) there may be a future path forward (if someone is so motivated). ___ 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
Re: The future of legacy BIOS support in Fedora.
>> This proposal was soundly rejected, so don't worry about it. > > That's great news. Thank you! I am not thrilled that this has been rejected since efi support is not so good on Fedora. Devices that are BIOS can IIRC still use efi using a boot tool installed to the MBR which emulates EFI and than loads the EFI loader. This would be a one time step. Hopefully Fedora will have enough resources to support systemd-boot on Fedora Silverblue, which has never worked so far due to ostree naming conventions https://github.com/ostreedev/ostree/issues/1951 ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 8:27 PM Michael Catanzaro wrote: > On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis > wrote: > > I'am also have Thikpads and MSI running BIOS and some of those > > machines still are the beast in some terms. Dropping BIOS would > > pretty much force me to use something else. > > I don't want to lose Fedora. > > This proposal was soundly rejected, so don't worry about it. > That's great news. Thank you! > > ___ > 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 > ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis wrote: I'am also have Thikpads and MSI running BIOS and some of those machines still are the beast in some terms. Dropping BIOS would pretty much force me to use something else. I don't want to lose Fedora. This proposal was soundly rejected, so don't worry about it. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 7:48 PM Stephen John Smoogen wrote: > > > On Mon, 19 Oct 2020 at 02:15, Subsentient > wrote: > >> I figure I'll add my two cents for as little as that's worth. >> >> Personally, I use extlinux with a custom, barebones configuration. On my >> EFI systems, I use syslinux EFI. I like the simplicity of syntax for >> syslinux's configuration and how small it is, but that's me, and it's not >> going to be everyone's preference. >> >> I also own several legacy BIOS based systems that cannot support EFI, and >> they work fine, including my daily driver Thinkpad T410. >> While I know it will still be possible for *very* advanced Linux users >> such as me to get Fedora working on BIOS systems with my own bootloader of >> choice even if Fedora drops support, it would create a maintenance nuisance >> if I need to boot a recovery ISO etc or reinstall Fedora from scratch, e.g. >> in drive failure. And, of course, most Fedora users can't easily swap out a >> bootloader, they just haven't spent the energy learning those parts of the >> OS. >> >> Though, that would hardly be my concern. As sad as I was to see i686 >> support dropped, I could at least understand the reasoning behind it, given >> how few people used it and how large of a maintenance task it was. I myself >> didn't really use any systems that needed it. This, however, is different. >> >> Personally, I despise GRUB2, that's why I switched to syslinux when >> distros dropped GRUB1. I find GRUB2 very bloated, needlessly complicated, >> with too many magic black boxes. >> That said, dropping BIOS support simply to adopt another bootloader in >> its place is a deeply disturbing proposition. There are many BIOS based >> systems still in service, and there will be for quite some time. >> >> My Thinkpad was manufactured in 2011 and still only supports BIOS. In >> 2012, I started seeing EFI-based PCs on the market due to Windows 8 and >> MSFT's push for secure boot. Apple was an exception, they started using EFI >> as soon as they switched to Intel. The rest of the world remained on BIOS >> until 2012. >> >> Are you seriously considering dropping support for all systems older than >> 8 years of age? Even if I could mostly work around such a decision, it >> would anger me and I imagine a great many other users, purely on >> ideological grounds. I would consider switching distributions, and I've >> been a Fedora loyalist since 2009. >> >> Do you remember when Linux was touted as a lightweight alternative for >> older PCs, and you could install flagship distros on grandma's PC to >> breathe new life into it? I do. I don't want to live in the timeline where >> the only distros that run on such things are puppy linux and similar. >> > > I'am also have Thikpads and MSI running BIOS and some of those machines still are the beast in some terms. Dropping BIOS would pretty much force me to use something else. I don't want to lose Fedora. > I think the issue is that people have rose coloured glasses about how much > 'life' we could get out of someone's older PC... and how old that desktop > was. In the 30 years I have worked in PC/Unix, I would say that before > 2004, it was rare that it breathed new life into 2+ year old technology as > much as that the Linux kernel worked with all the hardware by then. Working > on an 1985 i386 in 1993 with Linux was great, but it was not any faster > than Windows 3.11 for a lot of things. A i486 with Linux was not running as > 'fast' as a i586 with Windows 95 in 1997. You could get some better usage > from older hardware as long as you kept the tasks run meant to run in such > a 'limited' environment. But as soon as Grandpa wanted to open Netscape or > Staroffice.. you would watch a mouse crawl as you ran out of swap. > > Having upgraded lots of "Grand-pa's" computer for 2 decades, I can say > that their computers were rarely older than 4-5 years old until after 2008. > It is only after Moore's law 'broke' after 2003 stopped seeing doubling cpu > speeds every 18 months that trying to keep hardware useful longer than 5 > years has been possible. When clock speeds were no longer doubling and > 'standard' hardware memory bought came in a window of 2GB to 4 GB for a > decade, being able to keep hardware longer really started happening. At > that point, most of the time there was no giant performance boost for most > things people did on the computer and unless you were into gaming, or > professions using a CPU to its max... most people stuck with the old stuff. > > The issue is that while 'moore's' law was no longer doubling every > 18months it was still working and tasks had to be rewritten to work with > more cores/threads/etc. As that happened the software's need for more CPU > power has increased to the point were a 10+ year computer isn't very useful > for 'modern' software (browser and various applications). Instead if you > want to have something work on a 2012 system well.. just use software from > 2012. It
Re: The future of legacy BIOS support in Fedora.
On Mon, 19 Oct 2020 at 02:15, Subsentient wrote: > I figure I'll add my two cents for as little as that's worth. > > Personally, I use extlinux with a custom, barebones configuration. On my > EFI systems, I use syslinux EFI. I like the simplicity of syntax for > syslinux's configuration and how small it is, but that's me, and it's not > going to be everyone's preference. > > I also own several legacy BIOS based systems that cannot support EFI, and > they work fine, including my daily driver Thinkpad T410. > While I know it will still be possible for *very* advanced Linux users > such as me to get Fedora working on BIOS systems with my own bootloader of > choice even if Fedora drops support, it would create a maintenance nuisance > if I need to boot a recovery ISO etc or reinstall Fedora from scratch, e.g. > in drive failure. And, of course, most Fedora users can't easily swap out a > bootloader, they just haven't spent the energy learning those parts of the > OS. > > Though, that would hardly be my concern. As sad as I was to see i686 > support dropped, I could at least understand the reasoning behind it, given > how few people used it and how large of a maintenance task it was. I myself > didn't really use any systems that needed it. This, however, is different. > > Personally, I despise GRUB2, that's why I switched to syslinux when > distros dropped GRUB1. I find GRUB2 very bloated, needlessly complicated, > with too many magic black boxes. > That said, dropping BIOS support simply to adopt another bootloader in its > place is a deeply disturbing proposition. There are many BIOS based systems > still in service, and there will be for quite some time. > > My Thinkpad was manufactured in 2011 and still only supports BIOS. In > 2012, I started seeing EFI-based PCs on the market due to Windows 8 and > MSFT's push for secure boot. Apple was an exception, they started using EFI > as soon as they switched to Intel. The rest of the world remained on BIOS > until 2012. > > Are you seriously considering dropping support for all systems older than > 8 years of age? Even if I could mostly work around such a decision, it > would anger me and I imagine a great many other users, purely on > ideological grounds. I would consider switching distributions, and I've > been a Fedora loyalist since 2009. > > Do you remember when Linux was touted as a lightweight alternative for > older PCs, and you could install flagship distros on grandma's PC to > breathe new life into it? I do. I don't want to live in the timeline where > the only distros that run on such things are puppy linux and similar. > I think the issue is that people have rose coloured glasses about how much 'life' we could get out of someone's older PC... and how old that desktop was. In the 30 years I have worked in PC/Unix, I would say that before 2004, it was rare that it breathed new life into 2+ year old technology as much as that the Linux kernel worked with all the hardware by then. Working on an 1985 i386 in 1993 with Linux was great, but it was not any faster than Windows 3.11 for a lot of things. A i486 with Linux was not running as 'fast' as a i586 with Windows 95 in 1997. You could get some better usage from older hardware as long as you kept the tasks run meant to run in such a 'limited' environment. But as soon as Grandpa wanted to open Netscape or Staroffice.. you would watch a mouse crawl as you ran out of swap. Having upgraded lots of "Grand-pa's" computer for 2 decades, I can say that their computers were rarely older than 4-5 years old until after 2008. It is only after Moore's law 'broke' after 2003 stopped seeing doubling cpu speeds every 18 months that trying to keep hardware useful longer than 5 years has been possible. When clock speeds were no longer doubling and 'standard' hardware memory bought came in a window of 2GB to 4 GB for a decade, being able to keep hardware longer really started happening. At that point, most of the time there was no giant performance boost for most things people did on the computer and unless you were into gaming, or professions using a CPU to its max... most people stuck with the old stuff. The issue is that while 'moore's' law was no longer doubling every 18months it was still working and tasks had to be rewritten to work with more cores/threads/etc. As that happened the software's need for more CPU power has increased to the point were a 10+ year computer isn't very useful for 'modern' software (browser and various applications). Instead if you want to have something work on a 2012 system well.. just use software from 2012. It is still available. Sure you can install Linux on that 15 year old computer but if you have to tell the user well you can't actually use a browser, an editor or half the things you can do on your cheapest smart-phone.. what use is that computer? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an
Re: The future of legacy BIOS support in Fedora.
I figure I'll add my two cents for as little as that's worth. Personally, I use extlinux with a custom, barebones configuration. On my EFI systems, I use syslinux EFI. I like the simplicity of syntax for syslinux's configuration and how small it is, but that's me, and it's not going to be everyone's preference. I also own several legacy BIOS based systems that cannot support EFI, and they work fine, including my daily driver Thinkpad T410. While I know it will still be possible for *very* advanced Linux users such as me to get Fedora working on BIOS systems with my own bootloader of choice even if Fedora drops support, it would create a maintenance nuisance if I need to boot a recovery ISO etc or reinstall Fedora from scratch, e.g. in drive failure. And, of course, most Fedora users can't easily swap out a bootloader, they just haven't spent the energy learning those parts of the OS. Though, that would hardly be my concern. As sad as I was to see i686 support dropped, I could at least understand the reasoning behind it, given how few people used it and how large of a maintenance task it was. I myself didn't really use any systems that needed it. This, however, is different. Personally, I despise GRUB2, that's why I switched to syslinux when distros dropped GRUB1. I find GRUB2 very bloated, needlessly complicated, with too many magic black boxes. That said, dropping BIOS support simply to adopt another bootloader in its place is a deeply disturbing proposition. There are many BIOS based systems still in service, and there will be for quite some time. My Thinkpad was manufactured in 2011 and still only supports BIOS. In 2012, I started seeing EFI-based PCs on the market due to Windows 8 and MSFT's push for secure boot. Apple was an exception, they started using EFI as soon as they switched to Intel. The rest of the world remained on BIOS until 2012. Are you seriously considering dropping support for all systems older than 8 years of age? Even if I could mostly work around such a decision, it would anger me and I imagine a great many other users, purely on ideological grounds. I would consider switching distributions, and I've been a Fedora loyalist since 2009. Do you remember when Linux was touted as a lightweight alternative for older PCs, and you could install flagship distros on grandma's PC to breathe new life into it? I do. I don't want to live in the timeline where the only distros that run on such things are puppy linux and similar. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Monday, July 13, 2020 7:52:51 AM MST Przemek Klosowski via devel wrote: > On 7/10/20 5:22 PM, John M. Harris Jr wrote: > >> Android, actually, is trying to get it right by a) being a platform so > >> that common security updates are available from the platform owner, and > >> can be applied to everyone's system and b) having a secure remote update > >> method. > > > > The problem with implementing systems such as this is obvious.. If the end > > user cannot upload their own firmware, because the host has a hardware > > mechanism for checking the signature of the firmware, that's not good for > > the end user, it's harmful. It would mean they don't actually own the > > system, the vendor does. > > Yes, but it it's too easy (and can be triggered remotely) it becomes a > huge problem. > > I also want to be able to load alternative firmware---but it has to be > difficult, e.g. by requiring to disassemble the device and physically > access the electronics. This is precisely what we're trying to fight with the libreboot project. It should be as easy as possible, so that more end users can use FLOSS boot firmware. Vendors have no trouble making it difficult as it is. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
On 7/10/20 5:22 PM, John M. Harris Jr wrote: Android, actually, is trying to get it right by a) being a platform so that common security updates are available from the platform owner, and can be applied to everyone's system and b) having a secure remote update method. The problem with implementing systems such as this is obvious.. If the end user cannot upload their own firmware, because the host has a hardware mechanism for checking the signature of the firmware, that's not good for the end user, it's harmful. It would mean they don't actually own the system, the vendor does. Yes, but it it's too easy (and can be triggered remotely) it becomes a huge problem. I also want to be able to load alternative firmware---but it has to be difficult, e.g. by requiring to disassemble the device and physically access the electronics. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Sun, Jul 12, 2020 at 03:35:05AM +1000, Philip Rhoades wrote: > > Marginal costs are still costs. They add up _very_ quickly. > > > > If they can save $0.01 by eliminating a physical button, over a > > million-unit production run that's a cool $1 million of potantial > > profit. > Really? Yeah, yeah.. :) Even if I've lost the ability to do basic math, I think my point is still valid. If the NRE is less than the marginal BOM cost multiplied out by the expected production run, it's considered a net win. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ 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
Re: The future of legacy BIOS support in Fedora.
Solomon, On 2020-07-11 21:41, Solomon Peachy wrote: On Sat, Jul 11, 2020 at 10:03:47AM +0200, Nicolas Mailhot via devel wrote: The marginal cost of a button is completely marginal, on devices that already include other buttons, on a assembly line that already builds a ton of such things. Marginal costs are still costs. They add up _very_ quickly. If they can save $0.01 by eliminating a physical button, over a million-unit production run that's a cool $1 million of potantial profit. Really? P. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: p...@pricom.com.au ___ 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
Re: The future of legacy BIOS support in Fedora.
On Sat, Jul 11, 2020 at 10:03:47AM +0200, Nicolas Mailhot via devel wrote: > The marginal cost of a button is completely marginal, on devices that > already include other buttons, on a assembly line that already builds a > ton of such things. Marginal costs are still costs. They add up _very_ quickly. If they can save $0.01 by eliminating a physical button, over a million-unit production run that's a cool $1 million of potantial profit. Believe me, if they project that the NRE required to realize that cost savings comes in under $1M, they will make it happen. (Obviously the production volume is what determines what level of cost optimzation is worthwhile...) > A physical button is a on-of, a digital key infrastructure is years of > expensive maintenance and updates to keep going. The marginal cost of additional users of digital key infrastructure is infitesimal, especially if the widget already requires some sort of online service to function. The costs of that get covered by the subscrption fees. (and when there's no fee, the costs get covered by mining your data) Now the manufacturer may run the numbers and decide that using a physical button vs pure digital implementation reduces the _support_ costs, so it's better to stick with a button, but if we're being honest here most of the time post-sales lifecycle implications are rarely given any consideration at all. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ 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
Re: The future of legacy BIOS support in Fedora.
On Tue, Jul 7, 2020 at 6:17 AM Gerd Hoffmann wrote: > > On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered with, > > Well, if that is your concern the answer is secure boot. That will not > only prevent tampering with /boot files, but also prevent tampering with > the bootloader itself. Do review it. While "Trusted Computing" was blatantly aimed at DRM rather than user security, its use to lock down the boot process and prevent unauthorized bootloader access has been useful for high security devices in poor security physical environments. > > or config files haven't been read by somebody other than the end > > user. > > Hmm, typically that is pretty standard stuff and very simliar on all > fedora installs. Only the root filesystem uuid differs, and possibly > local tweaks like configuring a serial console. I can't see how reading > that is of much concern. > > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > filesystems. Splitting of "/boot" is *bad* a long-known problem. It used to be common place, but it makes disk size management that painful step more awkward for resizing sotrage in virtualization or physical environments. > > Is there a notable benefit to using that over GRUB2, which already has > > support on both UEFI and BIOS? > > Well, for my day-to-day work it doesn't make much of a difference. Both > get the job done. > > I generally dislike the grub2 config file format. I'm not going to > repeat all the arguments here which have been mentioned numerous times > already. With BLS support things became a bit better because for the > most part I can just ignore grub.cfg after install. It has problems, especially the lack of a useful "lint" for verifying new configs before deployment. I still sadly lament the lack of a "run this config as the default one time only, then revert to the other as default" which LILO supported and I used for testing kernels on new hardware. If the OS booted successfully, the init scripts would run a command to set the default to the new kernel, otherwise a failed boot would revert to the new kernel. Saved my company more than 1000 servers when a vendor did an unauthorized and incompatible hardware upgrade for brand new systems, and the production kernel we deployed on them failed to 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
Re: The future of legacy BIOS support in Fedora.
Le vendredi 10 juillet 2020 à 08:55 -0400, Przemek Klosowski a écrit : > > The marginal cost of a digital key has got to be smaller than the > marginal cost of the button The marginal cost of a button is completely marginal, on devices that already include other buttons, on a assembly line that already builds a ton of such things. A physical button is a on-of, a digital key infrastructure is years of expensive maintenance and updates to keep going. And as you noted they have to include physical bybass for other reasons. You’re used to computing costs as a software person, where hardware is an additional external expense. IOT manufacturers are first and foremost hardware people, they sell devices not bags of bits, they know how to make hardware as cheap as possible, and how to market hardware features so the marginal cost does not cost them a dime. Regards, -- Nicolas Mailhot ___ 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
Re: The future of legacy BIOS support in Fedora.
On Friday, July 10, 2020 5:05:51 AM MST Nicolas Mailhot via devel wrote: > Le vendredi 10 juillet 2020 à 07:51 -0400, Solomon Peachy a écrit : > > > On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel > > wrote: > > > > > If you remove end users from the loop there is zero zip nada need > > > for > > > secure boot in the first place. The sole function of secure boot > > > and > > > DRPM is to prevent end users, present in the update loop, from > > > doing > > > things the manufacturer disagreees with. > > > > > > s/manufacturer/device owner/ > > > Nope, manufacturer. There are hundreds of other simpler ways to protect > device owner side (physical locks on racks, 2FA auth via a physical > button on the device or an sms code, etc). > > The average device is not sold with locks in the supermarket. The home > or office or building or rack door is considered sufficient > protection. > > Evil maid does exist, but applying evil maid generally would require > putting locks on everything you buy, from the drawers where you may > store sensitive documents someday, to the fridge where the evil maid > may serve herself on your precious lagger. > > The threat scenario has been massively ovehyped to justify giving keys > to the manufacturers. Please note that SMS two factor has been known to be insecure since 2005, and NIST has recommended against it for just as long. (Before a bit of nonsense in 2016-2017, which I think has been corrected?) -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Friday, July 10, 2020 4:12:42 AM MST Przemek Klosowski via devel wrote: > On 7/10/20 5:06 AM, Nicolas Mailhot wrote: > > > The problem IOT side is not the security of the > > software update chain. The problem is that manufacturers skimp on > > software updates in the first place > > > Yes, that's the situation right now: everyone has a custom firmware tied > to a short product cycle---so new versions and fixes have to be > developed separately by everyone. This does not scale, and so it doesn't > happen most of the time. I think the only long-term solution is a wide > use of platforms, such as Android or Fedora. > > My point is that however the updates are being produced, they need a > secure remote update method. It's not realistic to expect end users to > be in the loop---it doesn't scale to the size the IOT is going to be. > Moreover, without the secure method, any vulnerability can be easily > converted to persistent breakage. > > Android, actually, is trying to get it right by a) being a platform so > that common security updates are available from the platform owner, and > can be applied to everyone's system and b) having a secure remote update > method. The problem with implementing systems such as this is obvious.. If the end user cannot upload their own firmware, because the host has a hardware mechanism for checking the signature of the firmware, that's not good for the end user, it's harmful. It would mean they don't actually own the system, the vendor does. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
On 7/10/20 8:25 AM, Nicolas Mailhot wrote: Le vendredi 10 juillet 2020 à 08:00 -0400, Przemek Klosowski a écrit : Not quite---as I said in next sentence that you didn't include in your quote, secure boot also tries to prevent unauthorized modifications, That does not work either, because if your system is remotely exploitable, it will just be remotely exploited at every boot, and there will be nothing stored persistently for secure boot to block (that is actually how some windows malware started to behave once Microsoft added boot protections). Except that you can fix the vulnerability, push the update and prevent the exploit, even if the vulnerability would somehow be in the boot firmware. For the exploit to win it would have to hit the window just after the boot, which can be prevented. The other usual argument is that digital keys are cheap and physical buttons or locks expensive. Well digital keys are definitely not cheap once you count all the work to keep digital protections up to date and bug free, and physical buttons are definitely not expensive. I have one on every bargain-bin iot plug in my house, to authorise initial pairing. And those buttons will keep working far after the IOT manufacturer will have screwed up the software update part. The marginal cost of a digital key has got to be smaller than the marginal cost of the button. At billions of device, that's the only cost that matters. Again, I am a hardware hacker and I hate the locked devices. But I think the secure updates have to happen, and it turns out that there is almost always a local bypass--JTAG, serial port, whatever. Maybe that is a regulatory issue---like a legal requirement that manufacturers need to publish a local unlock key/code after (or maybe even before) their support schedule ends. ___ 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
Re: The future of legacy BIOS support in Fedora.
Le vendredi 10 juillet 2020 à 08:00 -0400, Przemek Klosowski a écrit : > > > Not quite---as I said in next sentence that you didn't include in > your quote, secure boot also tries to prevent unauthorized > modifications, That does not work either, because if your system is remotely exploitable, it will just be remotely exploited at every boot, and there will be nothing stored persistently for secure boot to block (that is actually how some windows malware started to behave once Microsoft added boot protections). The other usual argument is that digital keys are cheap and physical buttons or locks expensive. Well digital keys are definitely not cheap once you count all the work to keep digital protections up to date and bug free, and physical buttons are definitely not expensive. I have one on every bargain-bin iot plug in my house, to authorise initial pairing. And those buttons will keep working far after the IOT manufacturer will have screwed up the software update part. Regards, -- Nicolas Mailhot ___ 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
Re: The future of legacy BIOS support in Fedora.
Le vendredi 10 juillet 2020 à 07:51 -0400, Solomon Peachy a écrit : > On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel > wrote: > > If you remove end users from the loop there is zero zip nada need > > for > > secure boot in the first place. The sole function of secure boot > > and > > DRPM is to prevent end users, present in the update loop, from > > doing > > things the manufacturer disagreees with. > > s/manufacturer/device owner/ Nope, manufacturer. There are hundreds of other simpler ways to protect device owner side (physical locks on racks, 2FA auth via a physical button on the device or an sms code, etc). The average device is not sold with locks in the supermarket. The home or office or building or rack door is considered sufficient protection. Evil maid does exist, but applying evil maid generally would require putting locks on everything you buy, from the drawers where you may store sensitive documents someday, to the fridge where the evil maid may serve herself on your precious lagger. The threat scenario has been massively ovehyped to justify giving keys to the manufacturers. -- Nicolas Mailhot ___ 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
Re: The future of legacy BIOS support in Fedora.
On 7/10/20 7:37 AM, Nicolas Mailhot wrote: Le vendredi 10 juillet 2020 à 07:12 -0400, Przemek Klosowski via devel a écrit : My point is that however the updates are being produced, they need a secure remote update method. It's not realistic to expect end users to be in the loop If you remove end users from the loop there is zero zip nada need for secure boot in the first place. The sole function of secure boot and DRPM is to prevent end users, present in the update loop, from doing things the manufacturer disagreees with. A system, that auto consults a remote update point, over https, checking the certificate of this remote point, has zero need for secure boot. Not quite---as I said in next sentence that you didn't include in your quote, secure boot also tries to prevent unauthorized modifications, for instance resulting from exploited vulnerabilities. It turns out that legitimate owners aren't the only users of IOT :) Look---I agree this is a complex situation. Secure boot has many consequences, and I share your concerns about many of them (walled gardens and loss of control over hardware we own). This does not change the fact that the current technology is inadequate and needs to evolve. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel wrote: > If you remove end users from the loop there is zero zip nada need for > secure boot in the first place. The sole function of secure boot and > DRPM is to prevent end users, present in the update loop, from doing > things the manufacturer disagreees with. s/manufacturer/device owner/ - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ 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
Re: The future of legacy BIOS support in Fedora.
Hello, Faye. On Saturday, 04 July 2020 at 00:42, Faye C. wrote: [...] > Because of the way Windows 10 is, UEFI is the only thing that is > accepted (no Legacy Boot). If I try any other OS on UEFI my laptop > can't find the disc image. It somehow seems to be designed only for > Windows 10. Legacy Boot is the only way that I can run a different OS. > Despite factory reseting it and doing a clean install of Windows 7, I > still can't use UEFI at all. My laptop isn't that old either, (about a > year and a half) in fact it was really hard to get my intel drivers > working since Intel doesn't support downgrading with newer hardware > that's designed for Windows 10 from what I can see. I'm new to Linux > and have only recently gotten used to Fedora, but if it goes to where > only UEFI is supported I will have to unfortunately go elsewhere. That sadly happens when vendors modify the reference UEFI firmware to support booting Windows only. For example, one of my machines has "Windows Boot Manager" hard-coded as the only boot entry it can boot, so I was able to boot Fedora with UEFI and SecureBoot enabled only by renaming the Fedora boot entry to "Windows Boot Manager". :) Regards, Dominik -- 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
Re: The future of legacy BIOS support in Fedora.
Le vendredi 10 juillet 2020 à 07:12 -0400, Przemek Klosowski via devel a écrit : > > My point is that however the updates are being produced, they need a > secure remote update method. It's not realistic to expect end users > to be in the loop If you remove end users from the loop there is zero zip nada need for secure boot in the first place. The sole function of secure boot and DRPM is to prevent end users, present in the update loop, from doing things the manufacturer disagreees with. A system, that auto consults a remote update point, over https, checking the certificate of this remote point, has zero need for secure boot. -- Nicolas Mailhot ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thu, Jul 9, 2020 at 5:20 PM Chris Adams wrote: > > Once upon a time, nick...@gmail.com said: > > To be honest, I don't know. Do all UEFI secure boot implementations > > allow you to add your own keys to the list of trusted keys? > > I believe that the Microsoft OEM Windows x86_64 distribution > requirements require UEFI, with Scure Boot enabled, and with the ability > for the system admin to add their own signing keys. So, most every > AMD/Intel system you run across should support that. I don't know this for sure, but from what I've heard, that last point (user management of keys) is no longer a requirement, as is being able to disable Secure Boot. Some of my friends have reported getting laptops from some big vendors without the ability to do either in the last couple of years. -- 真実はいつも一つ！/ 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
Re: The future of legacy BIOS support in Fedora.
On 7/10/20 5:06 AM, Nicolas Mailhot wrote: The problem IOT side is not the security of the software update chain. The problem is that manufacturers skimp on software updates in the first place Yes, that's the situation right now: everyone has a custom firmware tied to a short product cycle---so new versions and fixes have to be developed separately by everyone. This does not scale, and so it doesn't happen most of the time. I think the only long-term solution is a wide use of platforms, such as Android or Fedora. My point is that however the updates are being produced, they need a secure remote update method. It's not realistic to expect end users to be in the loop---it doesn't scale to the size the IOT is going to be. Moreover, without the secure method, any vulnerability can be easily converted to persistent breakage. Android, actually, is trying to get it right by a) being a platform so that common security updates are available from the platform owner, and can be applied to everyone's system and b) having a secure remote update method. ___ 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
Re: The future of legacy BIOS support in Fedora.
Le jeudi 09 juillet 2020 à 23:58 -0400, Przemek Klosowski via devel a écrit : > > While it's true that a completely secure software chain doesn't > really exist yet, we are slowly going in that direction, because it > is just inconceivable otherwise in the world with billions of > autonomous IOT devices That’s a joke isn’t it? The problem IOT side is not the security of the software update chain. The problem is that manufacturers skimp on software updates in the first place, and refuse to provide the length of support software-side, that users have come to expect hardware-side. Leading to vast deployments of abandoware. A lot of things, starting with the DRM target that funded secure boot, would not exist if manufacturers were serious about updates, because those systems are increadibly brittle and incompatible with a long term support view. -- Nicolas Mailhot ___ 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
Re: The future of legacy BIOS support in Fedora.
On 7/9/20 10:46 AM, John M. Harris Jr wrote: "Secure Boot" doesn't make root non-uid 0, and can't keep root from controlling system devices, even uploading unsigned firmware to peripherals. While it's true that a completely secure software chain doesn't really exist yet, we are slowly going in that direction, because it is just inconceivable otherwise in the world with billions of autonomous IOT devices---the consequences of a worm-type insecurity that would subvert a significant portion of Internet-connected devices are just too scary. For instance, one possible solution used e.g. for a secure BIOS updates is to prevent loading firmware directly, and instead load it into a separate flash area. Then, reset the system: * existing certified firmware boots and finds the updated firmware * new firmware is measured and verified * if it passes, the old firmware copies and activates the updated firmware So you see that you can't subvert this even with UID==0. Same thing for controlling system devices---with secure software chain even the applications can be certified and controlled. THis is not your or my desktop system, of course, but there is a need for systems like this. When I hear you say that this takes away the ownership of our computers from us, I think that it's got to be this way for a large part of those billions of systems---as the saying goes, we have to stop thinking of computers as pets, and start seeing them as cattle. We can still have pets as well, but there has to be a way to herd cattle. ___ 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
Re: The future of legacy BIOS support in Fedora.
Once upon a time, nick...@gmail.com said: > To be honest, I don't know. Do all UEFI secure boot implementations > allow you to add your own keys to the list of trusted keys? I believe that the Microsoft OEM Windows x86_64 distribution requirements require UEFI, with Scure Boot enabled, and with the ability for the system admin to add their own signing keys. So, most every AMD/Intel system you run across should support that. -- Chris Adams ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thu, 09 Jul 2020 23:10:46 +0300 nick...@gmail.com wrote: > On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote: > > That is, isn't this only an issue if the person doing the kernel > > development hasn't generated their own key, and isn't signing their > > kernels locally? > > To be honest, I don't know. Do all UEFI secure boot implementations > allow you to add your own keys to the list of trusted keys? I don't know, but I used Fedora tools to create the key pair, and insert the public key (x86_64). Anyway, just another data point in the discussion. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 23:10 +0300, nick...@gmail.com wrote: > On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote: > > On Thu, 09 Jul 2020 18:07:39 +0300 > > nick...@gmail.com wrote: > > > > > Yes, that's why "secure boot" should only be an option and the user > > > must have the option to turn it off. Otherwise, it wouldn't be > > > possible to do any kernel development on that computer. > > > > For my edification. I build custom kernels, and sign them using > > pesign with my own key that I generated locally, and put in the EFI > > key > > database. I can then boot the custom kernel in secure mode. Couldn't > > I > > also sign modules if I ever generated them with that same key? > > > > That is, isn't this only an issue if the person doing the kernel > > development hasn't generated their own key, and isn't signing their > > kernels locally? > > To be honest, I don't know. Do all UEFI secure boot implementations > allow you to add your own keys to the list of trusted keys? In theory they should, but the interface may be broken or overly complicated. That said you can always disable secure boot on x86_64 ... not so on ARM based hw. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote: > On Thu, 09 Jul 2020 18:07:39 +0300 > nick...@gmail.com wrote: > > > Yes, that's why "secure boot" should only be an option and the user > > must have the option to turn it off. Otherwise, it wouldn't be > > possible to do any kernel development on that computer. > > For my edification. I build custom kernels, and sign them using > pesign with my own key that I generated locally, and put in the EFI > key > database. I can then boot the custom kernel in secure mode. Couldn't > I > also sign modules if I ever generated them with that same key? > > That is, isn't this only an issue if the person doing the kernel > development hasn't generated their own key, and isn't signing their > kernels locally? To be honest, I don't know. Do all UEFI secure boot implementations allow you to add your own keys to the list of trusted keys? Nikolay ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thu, 09 Jul 2020 18:07:39 +0300 nick...@gmail.com wrote: > Yes, that's why "secure boot" should only be an option and the user > must have the option to turn it off. Otherwise, it wouldn't be > possible to do any kernel development on that computer. For my edification. I build custom kernels, and sign them using pesign with my own key that I generated locally, and put in the EFI key database. I can then boot the custom kernel in secure mode. Couldn't I also sign modules if I ever generated them with that same key? That is, isn't this only an issue if the person doing the kernel development hasn't generated their own key, and isn't signing their kernels locally? ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 07:46 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote: > > On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr < > > joh...@splentity.com> > > wrote: > > > This is not something that's beneficial here, it's only > > > harming our users. > > > > That seems exceedingly myopic to me. I'm guessing you've not been > > following the last few years of security research, where attacking > > the > > firmware is now the best way to own a machine. And please don't > > lecture me on why BIOS is more secure than UEFI, "compatibility" > > mode > > is implemented *on top of* the UEFI bios these days, rather than as > > a > > completely different software stack. > > "Attacking" the firmware has always been the best option, even with > BIOS boot > systems. For example, coreboot is technically a hostile payload, to > the OEM. > That doesn't mean that it makes any sense to prevent the end user > from > actually owning the hardware they've purchased, and doing with it > what they > please. Yes, that's why "secure boot" should only be an option and the user must have the option to turn it off. Otherwise, it wouldn't be possible to do any kernel development on that computer. > > > > If you've got root, you can STILL do almost anything to the > > > hardware, > > > including disabling various "firmware protection technologies". > > > > I don't think you understand what enabling SecureBoot actually > > does. > > "Secure Boot" doesn't make root non-uid 0, and can't keep root from > controlling system devices, even uploading unsigned firmware to > peripherals. > At the point that anything but the end user gets root on a Fedora > install, all > of these "security gains" provided by creating needless headache for > those > running under "Secure Boot" are null and void. Yeah, for me, it's pretty weak as a mitigation effort, because it will usually only have some protective effect if someone already has root on your computer, and that's already pretty bad. You don't normally want to allow that to happen ever. And when someone has root, they can do pretty much anything. IMHO, it's a lot of effort and inconvenience for very little actual gain. But, that's why it should only be an option and not mandatory. But yes, it might make sense for certain use cases. Nikolay ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thu, 2020-07-09 at 07:38 -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote: > > On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote: > > > > > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote: > > > > > > > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr < > > > > joh...@splentity.com> > > > > wrote: > > > > > > > > > needlessly disables a lot of kernel functionality > > > > > > > > > > > > It disables functionality which can destroy platform security. > > > > > > It disables functionality that users need, such as inserting > > > their kernel > > > > > > modules on their own system, or hibernating to disk. Let's be > > > honest about > > > what this does. This is not something that's beneficial here, > > > it's only > > > harming our users. > > > > Some users, not all users. Beware of making sweeping > > generalizations. > > > > I've used Fedora since Fedora Core 5 across countless machines and > > never > > cared about inserting custom kernel modules. Hibernating to disk is > > not > > something I've used on my laptops in probably 10 years either, as > > suspend > > to ram is generally sufficient. Again just my personal experiance. > > > > There's always a tradeoff and it is likely to be different > > depending on > > each users needs. While SecureBoot will disable some functionality > > it is > > not unreasonable to think it is a net win out of the box for a > > potentially > > quite large portion of Fedora's userbase. > > > > Regards, > > Daniel > > Please keep in mind that it disables that functionality only because > of > 'lockdown' patches applied to the Fedora kernel, it's not a normal > part of the > Linux kernel when running under Secure Boot. I have no idea why the > decision > to hurt users was explicitly made here, it doesn't make a lot of > sense. IIRC, if you sign a kernel that can load unsigned modules, you can boot that kernel, then load a custom module, that boots a different kernel or OS (such as Windows) and claim that secure boot was on, even though you have modified and/or injected malicious code into the kernel. In other words, you can circumvent the whole point of using secure boot. If you want that, you might as well just disable secure boot. Otherwise it is a bit like locking your front door, while leaving your back door widely open. You can argue all they long that secure boot doesn't bring you that much security anyway (I'm in that camp, I don't think it's worth the trouble for my home systems, so I disable them even on those that use UEFI), but then, again, as long as it's not mandatory, so the user can choose to turn it off, it should be ok. Some people might decide to make an informed decision to enable it, and that's their decision to make. It's a tradeoff - extra lockdown for some extra security. Maybe only worth it for very important systems. Nikolay ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote: > On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr > wrote: > > This is not something that's beneficial here, it's only > > harming our users. > > > That seems exceedingly myopic to me. I'm guessing you've not been > following the last few years of security research, where attacking the > firmware is now the best way to own a machine. And please don't > lecture me on why BIOS is more secure than UEFI, "compatibility" mode > is implemented *on top of* the UEFI bios these days, rather than as a > completely different software stack. "Attacking" the firmware has always been the best option, even with BIOS boot systems. For example, coreboot is technically a hostile payload, to the OEM. That doesn't mean that it makes any sense to prevent the end user from actually owning the hardware they've purchased, and doing with it what they please. > > If you've got root, you can STILL do almost anything to the hardware, > > including disabling various "firmware protection technologies". > > > I don't think you understand what enabling SecureBoot actually does. "Secure Boot" doesn't make root non-uid 0, and can't keep root from controlling system devices, even uploading unsigned firmware to peripherals. At the point that anything but the end user gets root on a Fedora install, all of these "security gains" provided by creating needless headache for those running under "Secure Boot" are null and void. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote: > On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote: > > > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote: > > > > > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr > > > wrote: > > > > > > > needlessly disables a lot of kernel functionality > > > > > > > > > > > > It disables functionality which can destroy platform security. > > > > > > It disables functionality that users need, such as inserting their kernel > > > > modules on their own system, or hibernating to disk. Let's be honest about > > what this does. This is not something that's beneficial here, it's only > > harming our users. > > > Some users, not all users. Beware of making sweeping generalizations. > > I've used Fedora since Fedora Core 5 across countless machines and never > cared about inserting custom kernel modules. Hibernating to disk is not > something I've used on my laptops in probably 10 years either, as suspend > to ram is generally sufficient. Again just my personal experiance. > > There's always a tradeoff and it is likely to be different depending on > each users needs. While SecureBoot will disable some functionality it is > not unreasonable to think it is a net win out of the box for a potentially > quite large portion of Fedora's userbase. > > Regards, > Daniel Please keep in mind that it disables that functionality only because of 'lockdown' patches applied to the Fedora kernel, it's not a normal part of the Linux kernel when running under Secure Boot. I have no idea why the decision to hurt users was explicitly made here, it doesn't make a lot of sense. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr wrote: > This is not something that's beneficial here, it's only > harming our users. That seems exceedingly myopic to me. I'm guessing you've not been following the last few years of security research, where attacking the firmware is now the best way to own a machine. And please don't lecture me on why BIOS is more secure than UEFI, "compatibility" mode is implemented *on top of* the UEFI bios these days, rather than as a completely different software stack. > If you've got root, you can STILL do almost anything to the hardware, > including disabling various "firmware protection technologies". I don't think you understand what enabling SecureBoot actually does. Richard. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote: > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote: > > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr > > wrote: > > > needlessly disables a lot of kernel functionality > > > > > > It disables functionality which can destroy platform security. > > It disables functionality that users need, such as inserting their kernel > modules on their own system, or hibernating to disk. Let's be honest about > what this does. This is not something that's beneficial here, it's only > harming our users. Some users, not all users. Beware of making sweeping generalizations. I've used Fedora since Fedora Core 5 across countless machines and never cared about inserting custom kernel modules. Hibernating to disk is not something I've used on my laptops in probably 10 years either, as suspend to ram is generally sufficient. Again just my personal experiance. There's always a tradeoff and it is likely to be different depending on each users needs. While SecureBoot will disable some functionality it is not unreasonable to think it is a net win out of the box for a potentially quite large portion of Fedora's userbase. 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
Re: The future of legacy BIOS support in Fedora.
On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote: > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr > wrote: > > needlessly disables a lot of kernel functionality > > > It disables functionality which can destroy platform security. It disables functionality that users need, such as inserting their kernel modules on their own system, or hibernating to disk. Let's be honest about what this does. This is not something that's beneficial here, it's only harming our users. > > You cannot load kernel modules you've built > > > If you can build and insert your own kernel module you can do almost > anything to the hardware, including disabling various firmware > protection technologies. > > tl;dr: if you care about platform security at all, enable secure boot. If you've got root, you can STILL do almost anything to the hardware, including disabling various "firmware protection technologies". This is needlessly kneecapping users. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
On 7/8/20 10:47 AM, John M. Harris Jr wrote: On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote: On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: Well, if that is your concern the answer is secure boot. That will not only prevent tampering with /boot files, but also prevent tampering with the bootloader itself. No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway, needlessly disables a lot of kernel functionality, which makes it completely unusable. You cannot load kernel modules you've built, hibernate your system, etc. Additionally, Secure Boot does not prevent tampering with /boot files. You can still change grub.cfg as you like. Yet here I am, happily using it, across multiple systems... ___ 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
Re: The future of legacy BIOS support in Fedora.
Once upon a time, Richard Hughes said: > tl;dr: if you care about platform security at all, enable secure boot. If you want to use interesting and useful kernel technologies (namely eBPF), disable secure boot. That's a real killer of secure boot IMHO. -- Chris Adams ___ 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
Re: The future of legacy BIOS support in Fedora.
On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr wrote: > needlessly disables a lot of kernel functionality It disables functionality which can destroy platform security. > You cannot load kernel modules you've built If you can build and insert your own kernel module you can do almost anything to the hardware, including disabling various firmware protection technologies. tl;dr: if you care about platform security at all, enable secure boot. Richard ___ 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
Re: The future of legacy BIOS support in Fedora.
On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote: > On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: > > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot > > > and > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > files you can find there are public anyway, you can download them from > > > the fedora servers. Encrypting /boot would make the boot process more > > > fragile for no benefit. > > > > > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered > > with, > > > Well, if that is your concern the answer is secure boot. That will not > only prevent tampering with /boot files, but also prevent tampering with > the bootloader itself. No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway, needlessly disables a lot of kernel functionality, which makes it completely unusable. You cannot load kernel modules you've built, hibernate your system, etc. Additionally, Secure Boot does not prevent tampering with /boot files. You can still change grub.cfg as you like. > > or config files haven't been read by somebody other than the end > > user. > > > Hmm, typically that is pretty standard stuff and very simliar on all > fedora installs. Only the root filesystem uuid differs, and possibly > local tweaks like configuring a serial console. I can't see how reading > that is of much concern. There's no reason to allow these files to be read to begin with, if the system is going to be encrypted. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mo, 06.07.20 21:58, Peter Robinson (pbrobin...@gmail.com) wrote: > > > > Less complexity in the boot chain, mainly. But the EFI drivers would > > need to be signed by MS, I think? That would massively complicate > > things. > > I believe that to be correct, of could Apply has control over that for > their platform, you'd also need to load them some how, I'm guessing > sd-boot could try loading/locking if it can't read a file system... > suddenly things start to head towards complexity again. Quite frankly, I don't see the point of using a different file system than VFAT here. You cannot avoid VFAT anyway, since that's the only thing EFI firmware can generally read, and hence your boot loader itself is always read from VFAT anyway. Throwing in another file system just increases the maintenance burden: previously you had one problem and now you have two problems. Given that the update cycles for boot loaders in a world where boot loaders do certificate management, TLS, HTTP, networking, IP, yadda yadda isn't much different from update cycles for kernels/initrds adding in a second, separate file system such as XFS or ext4 won't give you much additional data safety, it just gives you more code that can break. In particular as features such as boot counting/assessment require writable fs access from the boot loader, but that is very hard to tackle on journalling file systems (grub doesn't do it afaik), and basically means you need to maintain your own fully blown file system implementation. VFAT on the other hand is simple, its there anyway, you need to rely on it anyway and allows writing from firmware too. That all said, one feature I'd like to add to sd-boot is that we define a drop-in dir where you can put drivers in, and we'll load them all, one by one. The idea would be that distros can drop in XFS or ext4 drivers there, properly signed, and we'd load them, so that it doesn't matter to sd-boot which file system you actually pick: if you want XFS or ext4 then you can easily make it happen, just by dropping in their driver files, and things will just work. 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
Re: The future of legacy BIOS support in Fedora.
Once upon a time, Lennart Poettering said: > EFI SecureBoot uses PE signed executables. Secure Boot also triggers the Linux kernel to disable functionality, so should be avoided as a requirement (except when necessary to boot some other OSes). -- Chris Adams ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mo, 06.07.20 16:34, Neal Gompa (ngomp...@gmail.com) wrote: > Encryption != integrity/authentication. The only thing encryption > guarantees is that the data is not visible, not that it hasn't been > tampered with. Usually, dm-verity or dm-integrity is used for what > you're asking for. Android uses dm-verity, if I remember correctly. EFI SecureBoot uses PE signed executables. > Less complexity in the boot chain, mainly. But the EFI drivers would > need to be signed by MS, I think? That would massively complicate > things. Could use SHIM like everything else. 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
Re: The future of legacy BIOS support in Fedora.
On Tue, Jul 7, 2020 at 11:17 AM Gerd Hoffmann wrote: > > On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > files you can find there are public anyway, you can download them from > > > the fedora servers. Encrypting /boot would make the boot process more > > > fragile for no benefit. > > > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered with, > > Well, if that is your concern the answer is secure boot. That will not > only prevent tampering with /boot files, but also prevent tampering with > the bootloader itself. It's part of the solution, how exactly does secure-boot it deal with the initrd when isn't signed because it's generate on install, or changes to config files such as grub.cfg? It doesn't, you need technologies such as a TPM2 to measure and attest, and things like IMA to enforce policies. > > or config files haven't been read by somebody other than the end > > user. > > Hmm, typically that is pretty standard stuff and very simliar on all > fedora installs. Only the root filesystem uuid differs, and possibly > local tweaks like configuring a serial console. I can't see how reading > that is of much concern. There's lots of cases where that is a concern, if you can't trust one part of your boot chain can you trust any of it? > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > filesystems. > > > > Is there a notable benefit to using that over GRUB2, which already has > > support on both UEFI and BIOS? > > Well, for my day-to-day work it doesn't make much of a difference. Both > get the job done. > > I generally dislike the grub2 config file format. I'm not going to > repeat all the arguments here which have been mentioned numerous times > already. With BLS support things became a bit better because for the > most part I can just ignore grub.cfg after install. > > I suspect the grub2 maintainers have a different view on this. They > have to deal with the mess to make sure I don't have to. And on top > of that getting changes merged upstream to grub2 seems to be a PITA, > leading to a huge stack of patches in the fedora grub2 rpm ... Well the whole upstream situation has started improving recently and the number of patches is coming down and being unified. The whole stack of patches was fairly standard across distros. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > are not. Which makes sense to me. Why would you encrypt /boot? The > > files you can find there are public anyway, you can download them from > > the fedora servers. Encrypting /boot would make the boot process more > > fragile for no benefit. > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > encrypt /boot to ensure that your boot images have not been tampered with, Well, if that is your concern the answer is secure boot. That will not only prevent tampering with /boot files, but also prevent tampering with the bootloader itself. > or config files haven't been read by somebody other than the end > user. Hmm, typically that is pretty standard stuff and very simliar on all fedora installs. Only the root filesystem uuid differs, and possibly local tweaks like configuring a serial console. I can't see how reading that is of much concern. > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > filesystems. > > Is there a notable benefit to using that over GRUB2, which already has > support on both UEFI and BIOS? Well, for my day-to-day work it doesn't make much of a difference. Both get the job done. I generally dislike the grub2 config file format. I'm not going to repeat all the arguments here which have been mentioned numerous times already. With BLS support things became a bit better because for the most part I can just ignore grub.cfg after install. I suspect the grub2 maintainers have a different view on this. They have to deal with the mess to make sure I don't have to. And on top of that getting changes merged upstream to grub2 seems to be a PITA, leading to a huge stack of patches in the fedora grub2 rpm ... 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
Re: The future of legacy BIOS support in Fedora.
On Monday, July 6, 2020 3:03:05 PM MST Peter Robinson wrote: > > > It's less complex to maintain one solution for both types of boot, I'd > > > imagine. I'm not the one that'd be doing the work to support it, so far > > > be it from me to prevent somebody from doing so, but that's just what > > > it sounds like. Right now, we have one solution that works well for > > > both. > > > > > > > > > > > > > > If we wanted to be UEFI first, we could make BIOS boots emulate UEFI > > and boot through the UEFI chain all the way through. We already do > > this for some boards on ARM with U-Boot, if I remember correctly. If > > that were possible on x86, then we could get down to one boot chain > > path regardless. > > > No, U-Boot is the firmware, it now implements a UEFI interface as a > means of interacting with OS/bootloaders for booting OSes in a generic > manner. It's not emulated, it is the interface between the firmware > (U-Boot) and the computer, for aarch64 it's mandated that the board > firmware implement UEFI to be supported in Fedora, whether that's the > Tianocore, U-Boot or another third party implementation, open or > proprietary we don't care. > > Why would you wrap BIOS with another firmware implementation? You're > just making the problem worse. Fact is that while it won't go away > particularly fast we should actually be looking at sunsetting > traditional BIOS support, it's not secure or securable. MS has > mandated it for the Windows logo program to be certified HW since > Windows 8, they've now mandated that for server as well, in both cases > now requiring TPM2. > > Don't hack up BIOS support, it vaguely sort of works now, leave it > vaguely working and just let it be, it's not evolving. One day we'll > wake up and no one will be using it, the sooner the better. That day is still decades away, as others in this list have noted. I agree with the rest, of course. Just let it be. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
> > It's less complex to maintain one solution for both types of boot, I'd > > imagine. I'm not the one that'd be doing the work to support it, so far be > > it > > from me to prevent somebody from doing so, but that's just what it sounds > > like. Right now, we have one solution that works well for both. > > > > If we wanted to be UEFI first, we could make BIOS boots emulate UEFI > and boot through the UEFI chain all the way through. We already do > this for some boards on ARM with U-Boot, if I remember correctly. If > that were possible on x86, then we could get down to one boot chain > path regardless. No, U-Boot is the firmware, it now implements a UEFI interface as a means of interacting with OS/bootloaders for booting OSes in a generic manner. It's not emulated, it is the interface between the firmware (U-Boot) and the computer, for aarch64 it's mandated that the board firmware implement UEFI to be supported in Fedora, whether that's the Tianocore, U-Boot or another third party implementation, open or proprietary we don't care. Why would you wrap BIOS with another firmware implementation? You're just making the problem worse. Fact is that while it won't go away particularly fast we should actually be looking at sunsetting traditional BIOS support, it's not secure or securable. MS has mandated it for the Windows logo program to be certified HW since Windows 8, they've now mandated that for server as well, in both cases now requiring TPM2. Don't hack up BIOS support, it vaguely sort of works now, leave it vaguely working and just let it be, it's not evolving. One day we'll wake up and no one will be using it, the sooner the better. Peter ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 6, 2020 at 5:05 PM John M. Harris Jr wrote: > > On Monday, July 6, 2020 1:34:05 PM MST Neal Gompa wrote: > > On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr > > wrote: > > > > > > > > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > > > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot > > > > and > > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > > files you can find there are public anyway, you can download them from > > > > the fedora servers. Encrypting /boot would make the boot process more > > > > fragile for no benefit. > > > > > > > > > > > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > > encrypt /boot to ensure that your boot images have not been tampered with, > > > or config files haven't been read by somebody other than the end user. > > > > > > Encryption != integrity/authentication. The only thing encryption > > guarantees is that the data is not visible, not that it hasn't been > > tampered with. Usually, dm-verity or dm-integrity is used for what > > you're asking for. Android uses dm-verity, if I remember correctly. > > That's true, in an ideal world, one of these modules would be used. However, > LUKS is often sufficient to know that it hasn't been modified, depending on > the ciphers used, if it does load correctly. > It's not guaranteed though, and you shouldn't rely on that for verifying integrity if you care about that. You either will want an authenticated filesystem or use a dm stack configuration that includes authentication. > > > > sd-boot still wouldn't work out-of-the-box though, due to /boot being > > > > xfs not vfat and firmware typically not shipping with xfs drivers. > > > > > > > > > > > > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still > > > used for /boot in Fedora, by default. > > > > > > > > > > > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > > filesystems. > > > > > > > > > > > > Is there a notable benefit to using that over GRUB2, which already has > > > support on both UEFI and BIOS? > > > > > > > > > > > > Less complexity in the boot chain, mainly. But the EFI drivers would > > need to be signed by MS, I think? That would massively complicate > > things. > > It's less complex to maintain one solution for both types of boot, I'd > imagine. I'm not the one that'd be doing the work to support it, so far be it > from me to prevent somebody from doing so, but that's just what it sounds > like. Right now, we have one solution that works well for both. > If we wanted to be UEFI first, we could make BIOS boots emulate UEFI and boot through the UEFI chain all the way through. We already do this for some boards on ARM with U-Boot, if I remember correctly. If that were possible on x86, then we could get down to one boot chain path regardless. -- 真実はいつも一つ！/ 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
Re: The future of legacy BIOS support in Fedora.
On Monday, July 6, 2020 1:34:05 PM MST Neal Gompa wrote: > On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr > wrote: > > > > > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot > > > and > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > files you can find there are public anyway, you can download them from > > > the fedora servers. Encrypting /boot would make the boot process more > > > fragile for no benefit. > > > > > > > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered with, > > or config files haven't been read by somebody other than the end user. > > > Encryption != integrity/authentication. The only thing encryption > guarantees is that the data is not visible, not that it hasn't been > tampered with. Usually, dm-verity or dm-integrity is used for what > you're asking for. Android uses dm-verity, if I remember correctly. That's true, in an ideal world, one of these modules would be used. However, LUKS is often sufficient to know that it hasn't been modified, depending on the ciphers used, if it does load correctly. > > > sd-boot still wouldn't work out-of-the-box though, due to /boot being > > > xfs not vfat and firmware typically not shipping with xfs drivers. > > > > > > > > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still > > used for /boot in Fedora, by default. > > > > > > > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > filesystems. > > > > > > > > Is there a notable benefit to using that over GRUB2, which already has > > support on both UEFI and BIOS? > > > > > > > Less complexity in the boot chain, mainly. But the EFI drivers would > need to be signed by MS, I think? That would massively complicate > things. It's less complex to maintain one solution for both types of boot, I'd imagine. I'm not the one that'd be doing the work to support it, so far be it from me to prevent somebody from doing so, but that's just what it sounds like. Right now, we have one solution that works well for both. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
> > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered with, > > or > > config files haven't been read by somebody other than the end user. > > > > Encryption != integrity/authentication. The only thing encryption > guarantees is that the data is not visible, not that it hasn't been > tampered with. Usually, dm-verity or dm-integrity is used for what > you're asking for. Android uses dm-verity, if I remember correctly. Or measurement and attestation via TPM2. > > > sd-boot still wouldn't work out-of-the-box though, due to /boot being > > > xfs not vfat and firmware typically not shipping with xfs drivers. > > > > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used > > for /boot in Fedora, by default. > > > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > filesystems. > > > > Is there a notable benefit to using that over GRUB2, which already has > > support > > on both UEFI and BIOS? > > > > Less complexity in the boot chain, mainly. But the EFI drivers would > need to be signed by MS, I think? That would massively complicate > things. I believe that to be correct, of could Apply has control over that for their platform, you'd also need to load them some how, I'm guessing sd-boot could try loading/locking if it can't read a file system... suddenly things start to head towards complexity again. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr wrote: > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > are not. Which makes sense to me. Why would you encrypt /boot? The > > files you can find there are public anyway, you can download them from > > the fedora servers. Encrypting /boot would make the boot process more > > fragile for no benefit. > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > encrypt /boot to ensure that your boot images have not been tampered with, or > config files haven't been read by somebody other than the end user. > Encryption != integrity/authentication. The only thing encryption guarantees is that the data is not visible, not that it hasn't been tampered with. Usually, dm-verity or dm-integrity is used for what you're asking for. Android uses dm-verity, if I remember correctly. > > > sd-boot still wouldn't work out-of-the-box though, due to /boot being > > xfs not vfat and firmware typically not shipping with xfs drivers. > > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used > for /boot in Fedora, by default. > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > filesystems. > > Is there a notable benefit to using that over GRUB2, which already has support > on both UEFI and BIOS? > Less complexity in the boot chain, mainly. But the EFI drivers would need to be signed by MS, I think? That would massively complicate things. -- 真実はいつも一つ！/ 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
Re: The future of legacy BIOS support in Fedora.
On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > are not. Which makes sense to me. Why would you encrypt /boot? The > files you can find there are public anyway, you can download them from > the fedora servers. Encrypting /boot would make the boot process more > fragile for no benefit. I guess that shows how unfamiliar I am with UEFI boot Fedora. You would encrypt /boot to ensure that your boot images have not been tampered with, or config files haven't been read by somebody other than the end user. > sd-boot still wouldn't work out-of-the-box though, due to /boot being > xfs not vfat and firmware typically not shipping with xfs drivers. If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used for /boot in Fedora, by default. > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > filesystems. Is there a notable benefit to using that over GRUB2, which already has support on both UEFI and BIOS? -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
Hi,
On 7/6/20 9:36 PM, John M. Harris Jr wrote:
On Monday, July 6, 2020 5:51:40 AM MST Gerd Hoffmann wrote:
Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
file for the latter is so short that I can include it here without
hitting the mailing list size limit ;)
-- cut here --
function load_video {
insmod all_video
}
insmod part_gpt
insmod fat
insmod serial
insmod terminal
insmod blscfg
serial --unit=0 --speed=115200
terminal_output console serial
terminal_input console serial
set boot='hd0,gpt2'
set timeout=3
blscfg
-- cut here --
Does that actually include the drivers necessary to use your keyboard?
Somebody pointed out to me, in private, that the drivers for their keyboard
weren't loaded in the current Workstation GRUB2 config.
UEFI grub uses the EFI provided keyboard drivers, if the keyboard
does not work in grub then that someone likely has "fastboot" enabled
in his BIOS and he has a BIOS which skips all USB device setup when
this is enabled.
UEFI firmware which supports some form of fastboot is supposed to delay
scanning the USB bus until we ask for input (and we currently always
ask for input) but many BIOS-es do not delay, but instead entirely skip,
scanning the USB bus when their fastboot or equivalent option is on.
Regards,
Hans
___
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
Re: The future of legacy BIOS support in Fedora.
On Monday, July 6, 2020 2:10:18 AM MST Jóhann B. Guðmundsson wrote: > On 5.7.2020 19:31, Solomon Peachy wrote: > > > On Sun, Jul 05, 2020 at 07:18:47PM -, Tom Seewald wrote: > > > >> In terms of physical x86 systems, you are right that UEFI is the > >> overwhelming majority. But as stated elsewhere in this thread, a lot > >> of cloud providers and virtualization software default to using BIOS. > >> So I think Fedora should only start considering dropping BIOS support > >> once the default is UEFI on most virtualization platforms. > > > > FWIW, I completely agree with this. > > > > As do I. > > Hopefully Daniel's response of the poor state those tools are in, will > raise some red flags within Red Hat in which it starts throwing some > resources ( money,workforce) to have this addressed before RHEL 9 gets > released. > > Atleast that is what I would do if I was a person in power within Red > Hat ( or a company that provides or relies on a solution based on those > tools) and had read his response which described quite the "alarming > situation" for products within the company in relation where the > industry is heading. I don't understand why you're trying to light fires for no reason. What we have now works on all platforms already, including UEFI. If every existing system dropped BIOS support *today*, we'd still be fine. Please don't exaggerate the importance of these issues. We have a working UEFI solution with GRUB2, which also works well for BIOS. There is no reason for RHEL to drop BIOS either, in fact, they have more reason to support it than Fedora: So their customers can continue to use their product. -- John M. Harris, Jr. ___ 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
Re: The future of legacy BIOS support in Fedora.
On 6.7.2020 12:07, Tomasz Torcz wrote: On Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote: The BIOS provides block device access at sector level, so the boot loader has little choice but implementing drivers for all kinds of stuff. Or use fragile block lists like lilo did in the last century. With UEFI much more functionality is provided by the firmware and there is little reason for a bootloader to have tons of drivers. With the exception of filesystem drivers in case you want boot from something != vfat. But even that should ideally be implemented as uefi driver not as grub2 module. FWIW, there seem to be UEFI driver for btrfs, ZFS, XFS and others: https://efi.akeo.ie/ Thanks this was very helpful. 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
Re: The future of legacy BIOS support in Fedora.
On Monday, July 6, 2020 5:51:40 AM MST Gerd Hoffmann wrote:
> Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
> file for the latter is so short that I can include it here without
> hitting the mailing list size limit ;)
>
> -- cut here --
> function load_video {
> insmod all_video
> }
>
> insmod part_gpt
> insmod fat
> insmod serial
> insmod terminal
> insmod blscfg
>
> serial --unit=0 --speed=115200
> terminal_output console serial
> terminal_input console serial
>
> set boot='hd0,gpt2'
> set timeout=3
> blscfg
> -- cut here --
Does that actually include the drivers necessary to use your keyboard?
Somebody pointed out to me, in private, that the drivers for their keyboard
weren't loaded in the current Workstation GRUB2 config.
--
John M. Harris, Jr.
___
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
Re: The future of legacy BIOS support in Fedora.
On 6.7.2020 18:39, Javier Martinez Canillas wrote: On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson wrote: On 5.7.2020 18:34, Javier Martinez Canillas wrote: On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote: [snip] Please submit additions to the spec as PRs to systemd github. We added a number of new keys in the past that sd-boot itself doesn't make use of (devicetree and such), and we'd be delighted to add more if they make sense and that helps. Thanks. I'll discuss this with the rest of the bootloader folks and think how the spec could be extended to cover the remaining cases where variable expansion is still used for GRUB. The new keys could be generic and even benefit other bootloaders if they implement these features at some point (e.g: boot entries protection). Since you are in contact with and thus presumably you are one of the "bootloader folks" could you clarify who those individual are and what role they play and which bootloaders they represent in the distribution and on which arch etc. and where they can be contacted ( mailinglist ) since I don't find any documentation about any bootloader WG existing within Fedora yet such a team seems to exist since it's being mentioned. Sure, I meant the members of the Red Hat bootloader team (Peter Jones, Jan Hlavac and me) and people who are not part of the bootloader team but work very closely with us and help to improve the boot stack in general. Mostly Hans de Goede and Christian Kellner but also others. Peter maintains all the projects in https://github.com/orgs/rhboot and their respective packages in Fedora. And I help him with that work. We are also involved in the upstream communities of the bootloaders that are used in the architectures supported by Fedora. These are: - GRUB (x86_64 legacy BIOS and EFI, aarch64 EFI and ppc64le OF) - Petitboot (ppc64le OPAL) - zipl (s390x) - u-boot (armv7). But for the last two most of the work and the package maintenance is done by Dan Horák (s390utils-base) and Peter Robinson (uboot-images-armv7). All these people can be contacted in the Fedora devel mailing list. I hope this answers your question, please let me know if you need more details. This was precisely the info I was looking for. Thanks 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
Re: The future of legacy BIOS support in Fedora.
Out of the 2 computers I own, 2 only boot through legacy BIOS. One claims to have UEFI support but I haven't managed to get it running with tens of hours of work over the years. In other words: I think it is too early to drop support for this legacy technology. ___ 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
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson wrote: > > On 5.7.2020 18:34, Javier Martinez Canillas wrote: > > On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering > > wrote: > > > > [snip] > > > >> Please submit additions to the spec as PRs to systemd github. We added > >> a number of new keys in the past that sd-boot itself doesn't make use > >> of (devicetree and such), and we'd be delighted to add more if they > >> make sense and that helps. > >> > > Thanks. I'll discuss this with the rest of the bootloader folks and > > think how the spec could be extended to cover the remaining cases > > where variable expansion is still used for GRUB. The new keys could be > > generic and even benefit other bootloaders if they implement these > > features at some point (e.g: boot entries protection). > > Since you are in contact with and thus presumably you are one of the > "bootloader folks" could you clarify who those individual are and what > role they play and which bootloaders they represent in the distribution > and on which arch etc. and where they can be contacted ( mailinglist ) > since I don't find any documentation about any bootloader WG existing > within Fedora yet such a team seems to exist since it's being mentioned. > Sure, I meant the members of the Red Hat bootloader team (Peter Jones, Jan Hlavac and me) and people who are not part of the bootloader team but work very closely with us and help to improve the boot stack in general. Mostly Hans de Goede and Christian Kellner but also others. Peter maintains all the projects in https://github.com/orgs/rhboot and their respective packages in Fedora. And I help him with that work. We are also involved in the upstream communities of the bootloaders that are used in the architectures supported by Fedora. These are: - GRUB (x86_64 legacy BIOS and EFI, aarch64 EFI and ppc64le OF) - Petitboot (ppc64le OPAL) - zipl (s390x) - u-boot (armv7). But for the last two most of the work and the package maintenance is done by Dan Horák (s390utils-base) and Peter Robinson (uboot-images-armv7). All these people can be contacted in the Fedora devel mailing list. I hope this answers your question, please let me know if you need more details. 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
Re: The future of legacy BIOS support in Fedora.
On Mon, 2020-07-06 at 14:51 +0200, Gerd Hoffmann wrote: > Hi, > > > My real problem with grub2 is not that it's complex, but the fact > > that > > it exposes its complexities to the user. > > The config file syntax is a mess indeed. The fact that you need a > config generator tool in the first place speaks volumes ... > > But note that grub config files don't have to be as complex as the > grub2-mkconfig generated ones. > > > I'm willing to try systemd-boot on a virtual machine, to see if it > > makes things easier, but the fact it doesn't support BIOS makes it > > not > > very usable for me. > > https://www.kraxel.org/repos/images/fedora-31-efi-systemd-x86_64.qcow2.xz > Thanks! I downloaded the image and will check it out as soon as I find some free time... :) Best regards, Nikolay ___ 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
Re: The future of legacy BIOS support in Fedora.
Le 2020-07-06 16:33, Gerd Hoffmann a écrit :
On Mon, Jul 06, 2020 at 03:45:45PM +0200, Nicolas Mailhot via devel
wrote:
Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> Â Â Hi,
>
> See above. sd-boot allows to edit the kernel command line too. Same
> hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> actually listed if you hit '?' or 'h'.
Given the mess boot input and display are on a lot of systems, any
keypress should pause the boot and display boot options (including
editing the boot CLI).
Sure. All bootloaders I have seen in recent years (including sd-boot)
behave that way.
I was mostly reacting to
And unlike the 'l' and 'w' hotkeys that one is actually listed if you
hit '?' or 'h'.
Regards,
--
Nicolas Mailhot
___
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
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 06, 2020 at 03:45:45PM +0200, Nicolas Mailhot via devel wrote:
> Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> > Â Â Hi,
> >
> > See above. sd-boot allows to edit the kernel command line too. Same
> > hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> > actually listed if you hit '?' or 'h'.
>
> Given the mess boot input and display are on a lot of systems, any
> keypress should pause the boot and display boot options (including
> editing the boot CLI).
Sure. All bootloaders I have seen in recent years (including sd-boot)
behave that way. Even if a key has no specific function attached
pressing it will at least stop the timeout countdown. So I'm not sure
why you are bringing that up and what you are trying to say ...
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
Re: The future of legacy BIOS support in Fedora.
On Mon, 2020-07-06 at 15:33 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > default entry highlighted, a few seconds timeout with countdown. Both
> > > support editing boot entries.
> > Anecdata, but I definitely never (maybe once 15 years ago?) had grub
> > install issue, but plenty of dracut reconfiguration/upgrade failures
> > over the years and the ability to edit the command line has been a life
> > sacver.
>
> See above. sd-boot allows to edit the kernel command line too. Same
> hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> actually listed if you hit '?' or 'h'.
Ah this is good, sorry I must have misunderstood what you were saying.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
___
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
Re: The future of legacy BIOS support in Fedora.
Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> Hi,
>
> > > default entry highlighted, a few seconds timeout with countdown.
> > > Both
> > > support editing boot entries.
>
> > Anecdata, but I definitely never (maybe once 15 years ago?) had
> > grub
> > install issue, but plenty of dracut reconfiguration/upgrade
> > failures
> > over the years and the ability to edit the command line has been a
> > life
> > sacver.
>
> See above. sd-boot allows to edit the kernel command line too. Same
> hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> actually listed if you hit '?' or 'h'.
Given the mess boot input and display are on a lot of systems, any
keypress should pause the boot and display boot options (including
editing the boot CLI).
Otherwise you end up in keypress & display timing hell (not to mention
that non-qwerty users have the additional hurdle of guessing where keys
are mapped, which is why using anything except escape/space and
function keys will break hard in the field).
Regards,
--
Nicolas Mailhot
___
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
Re: The future of legacy BIOS support in Fedora.
Hi,
> > default entry highlighted, a few seconds timeout with countdown. Both
> > support editing boot entries.
> Anecdata, but I definitely never (maybe once 15 years ago?) had grub
> install issue, but plenty of dracut reconfiguration/upgrade failures
> over the years and the ability to edit the command line has been a life
> sacver.
See above. sd-boot allows to edit the kernel command line too. Same
hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
actually listed if you hit '?' or 'h'.
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
Re: The future of legacy BIOS support in Fedora.
Hi, On Mon, 2020-07-06 at 13:31 +0200, Gerd Hoffmann wrote: > Hi, > > > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > > "w" pressed down it will automatically boot into windows, similar if > > > you keep "l" pressed down it will automaticall boot into linux, "a" > > > will boot into macos, all without showing any UI at all. This means > > > the boot menu can be hidden entirely during boot with a zero timeout, > > > but you can still boot into a specific boot entry. > > > > That's actually awful, in my opinion, > > Why? It's nice to have them and I can't see any downsides. I have lots of machines that fail to show the exact time boot happens (external monitor still powering up or blanking out) and will disable/ignore keys if you press too early. You won't see this with laptops as they are integrated machines and manufacturers pay a lot more attention to having a smooth display experience, but with workstations or servers the boot time is not the best experience ... > > and objectively undiscoverable.. > > Indeed. Would be nice to show these hotkeys somewhere. Extend the > help line which is shown when you press '?' for example. > > > If you'd like to see how it should be done, boot a VM with GRUB2 as > > the bootloader. For a short period of time, you'll see a list of > > options, with the default option highlighted. If you don't pick > > something different, or don't need to enter a prompt to recover your > > device, it'll automatically boot. > > Well, seems you have never actually used sd-boot ... > > There actually isn't much of a difference between grub2 and systemd-boot > here. Both can be configured to show or not show a menu. The menu > screen doesn't look fundamentally different either: List of boot > entries for the kernels installed, entry to boot into firmware setup, > default entry highlighted, a few seconds timeout with countdown. Both > support editing boot entries. > > Yes, unlike grub2 sd-boot has no command prompt. I have not missed that > so far. The vast majority of cases where I've actually needed the grub2 > prompt have been grub2 install problems, like grub2 failing to find its > config file for some reason. That is clearly not something I account in > favor of grub2 ... Anecdata, but I definitely never (maybe once 15 years ago?) had grub install issue, but plenty of dracut reconfiguration/upgrade failures over the years and the ability to edit the command line has been a life sacver. It is kind of a must have feature to do development on kernels so you can quickly change something w/o breaking your written down configuration for good if you make a mistake. Definitely not a fan of having to try a rescue disk, when you are 1000 miles from a server that you can access only via a remote console. That said I do not love grub, but being able to change the boot line is really a basic required feature for a developer OS. > > GRUB2 is nice in that it's powerful enough for those that need it, but > > simple enough for those who don't want the complex features. > > Well, alot of the complex grub features are dragged forward from the > BIOS world to the UEFI world and are somewhat awkward there. > > The BIOS provides block device access at sector level, so the boot > loader has little choice but implementing drivers for all kinds of > stuff. Or use fragile block lists like lilo did in the last century. > > With UEFI much more functionality is provided by the firmware and there > is little reason for a bootloader to have tons of drivers. With the > exception of filesystem drivers in case you want boot from something != > vfat. But even that should ideally be implemented as uefi driver not as > grub2 module. > > If you insist on comparing bloat it will be grub2 which is bloated, > and it comes from being stuck in its own world and carrying its own > implementation for everything instead of using firmware services. > > -rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi > -rwx--. 1 root root 2513224 Jun 19 18:24 grubx64.efi > > (binaries as shipped by fedora 32). > > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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:
Re: The future of legacy BIOS support in Fedora.
Hi,
> My real problem with grub2 is not that it's complex, but the fact that
> it exposes its complexities to the user.
The config file syntax is a mess indeed. The fact that you need a
config generator tool in the first place speaks volumes ...
But note that grub config files don't have to be as complex as the
grub2-mkconfig generated ones.
> I'm willing to try systemd-boot on a virtual machine, to see if it
> makes things easier, but the fact it doesn't support BIOS makes it not
> very usable for me.
https://www.kraxel.org/repos/images/fedora-31-efi-systemd-x86_64.qcow2.xz
Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
file for the latter is so short that I can include it here without
hitting the mailing list size limit ;)
-- cut here --
function load_video {
insmod all_video
}
insmod part_gpt
insmod fat
insmod serial
insmod terminal
insmod blscfg
serial --unit=0 --speed=115200
terminal_output console serial
terminal_input console serial
set boot='hd0,gpt2'
set timeout=3
blscfg
-- cut here --
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
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 06, 2020 at 08:08:48AM -0400, Stephen John Smoogen wrote: > On Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann wrote: > > > > Hi, > > > > > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > > > "w" pressed down it will automatically boot into windows, similar if > > > > you keep "l" pressed down it will automaticall boot into linux, "a" > > > > will boot into macos, all without showing any UI at all. This means > > > > the boot menu can be hidden entirely during boot with a zero timeout, > > > > but you can still boot into a specific boot entry. > > > > > > That's actually awful, in my opinion, > > > > Why? It's nice to have them and I can't see any downsides. > > > > It isn't that you put the keyboard strokes, it is that you are saying > you can do a zero-timeout without problems. Ah, ok. I meant specifically the hotkey existing. I clearly can see that hiding the boot menu has its downsides and in fact most of my machines are configured to show it (and I think server actually defaults to menu=on, only workstatiion has menu=off by default). That is doesn't matter much for the uefi/bios and grub2/sd-boot discussion though, both boot loaders can be configured to whatever timeout you like. > 4. Screen flickering and paused screens. The lenovos I have do weird > things when attached to external monitors. Screens will stick on > monitors during the boot up sequence sometimes.. or they will do sync > tests which drop the entire video for 3-5 seconds at a time. I have a 4k monitor connected to a intel nuc, and grub has a 30s timeout there because it takes *ages* for the screen to sync. And even with the 30s timeout I don't see the menu now and then. The other extreme are laptop panels which typically sync within the fraction of a second where all this is not a problem at all. 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
Re: The future of legacy BIOS support in Fedora.
On Sun, Jul 05, 2020 at 01:11:08AM -0700, John M. Harris Jr wrote: > On Sunday, July 5, 2020 1:03:34 AM MST Luya Tshimbalanga wrote: > > It would be great that the installer, Anaconda, enables sd-boot for > > users running on UEFI system. The method was done before with both LILO > > and Grub decades ago and it was very surprising very few thought of that > > process especially for a distribution aiming to use latest technology. > > > > The question is for contributors running on legacy BIOS if they are > > willing to maintain it while the installer can focus to effectively use > > sd-boot. > > systemd-boot isn't really an option. It doesn't have the features that are > necessary for Fedora systems to actually be able to boot. It'd work on > Workstation, maybe, if they think their users will never need to know they're > even using a bootloader, and won't put /boot on LVM or LUKs encrypt it. Default fedora disk layout in UEFI mode is partitions for ESP, /boot and LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot are not. Which makes sense to me. Why would you encrypt /boot? The files you can find there are public anyway, you can download them from the fedora servers. Encrypting /boot would make the boot process more fragile for no benefit. sd-boot still wouldn't work out-of-the-box though, due to /boot being xfs not vfat and firmware typically not shipping with xfs drivers. We could that by using vfat for /boot. Or by shipping & using xfs.efi, simliar to how apple ships & uses apfs.efi to boot macOS from apfs filesystems. 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
