Re: The future of legacy BIOS support in Fedora.

2020-07-13 Thread John M. Harris Jr
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.

2020-07-13 Thread Przemek Klosowski via devel

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.

2020-07-11 Thread Solomon Peachy
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.

2020-07-11 Thread Philip Rhoades

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.

2020-07-11 Thread Solomon Peachy
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.

2020-07-11 Thread Nico Kadel-Garcia
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.

2020-07-11 Thread Nicolas Mailhot via devel
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.

2020-07-10 Thread John M. Harris Jr
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.

2020-07-10 Thread John M. Harris Jr
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.

2020-07-10 Thread Przemek Klosowski via devel

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.

2020-07-10 Thread Nicolas Mailhot via devel
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.

2020-07-10 Thread Nicolas Mailhot via devel
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.

2020-07-10 Thread Przemek Klosowski via devel

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.

2020-07-10 Thread Solomon Peachy
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.

2020-07-10 Thread Solomon Peachy
On Fri, Jul 10, 2020 at 07:18:06AM -0400, Neal Gompa wrote:
> 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.

The System.Fundamentals.Firmware.UEFISecureBoot section of the current 
WHCP v2004 documentation [1] states that:

"For devices that are designed to always boot with a specific secure 
 boot configuration, the two requirements ... to support Custom Mode 
 and the ability to disable Secure Boot are optional."

(Custom mode: "It shall be possible for a physically present user...  to 
 modify the contents of the secure boot signature databases and the PK...")

(Enable/Disable: "A physically presnet user must be allowed to disable 
 secure boot via firmware setup... programmatic disabling of secure boot 
 during boot services or after exiting boot services MUST NOT be 
 possible")

Note that "specific secure boot configuration" and "locked down 
platforms" are not defined in this document, but appears to only apply 
to ARM-based platforms]

Additionally, in System.Fundamentals.Firmware.UEFICompatibility

"All Windows systems must boot in UEFI mode by default. Other 
 requirements may add additional sections of compatibility to this list, 
 but this is the baseline."

"All systems, except servers, must be certified in UEFI mode without 
 activating CSM. If a system is available with 32bit and/or 64bit UEFI, 
 both configurations must be tested for certification."

And in System.Fundamentals.Firmware.UEFILegacyFallback:

"If the system ships with a UEFI-compatible OS, system firmware must be 
 implemented as UEFI and it must be able to achieve UEFI boot mode by 
 default. Such a system may also support fallback to legacy BIOS boot on 
 systems with OS which do not support UEFI, but only if the user selects 
 that option in a pre-boot firmware user interface. Legacy option ROMs 
 also may not be loaded by default."

"An OEM may not ship a 64-bit system which defaults to legacy BIOS ... 
 if that systems ships with a UEFI-compatible OS"

The language about servers is a bit muddled but it seems to say that if 
you're going to ship a 64-bit Windows install it needs to default to, 
and be certified with, CSM-less UEFI booting.  Secure boot is not a 
requirement for servers.

[1] 
https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/whcp-specifications-policies

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

2020-07-10 Thread Dominik 'Rathann' Mierzejewski
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.

2020-07-10 Thread Nicolas Mailhot via devel
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.

2020-07-10 Thread Neal Gompa
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.

2020-07-10 Thread Przemek Klosowski via devel

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.

2020-07-10 Thread Nicolas Mailhot via devel
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.

2020-07-09 Thread Przemek Klosowski via devel

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.

2020-07-09 Thread Chris Adams
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.

2020-07-09 Thread stan via devel
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.

2020-07-09 Thread Simo Sorce
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.

2020-07-09 Thread nickysn
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.

2020-07-09 Thread stan via devel
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.

2020-07-09 Thread nickysn
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.

2020-07-09 Thread nickysn
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.

2020-07-09 Thread John M. Harris Jr
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.

2020-07-09 Thread John M. Harris Jr
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.

2020-07-09 Thread Richard Hughes
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.

2020-07-09 Thread Daniel P . Berrangé
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.

2020-07-08 Thread John M. Harris Jr
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.

2020-07-08 Thread Brandon Nielsen

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.

2020-07-08 Thread Chris Adams
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.

2020-07-08 Thread Richard Hughes
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.

2020-07-08 Thread John M. Harris Jr
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.

2020-07-07 Thread Lennart Poettering
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.

2020-07-07 Thread Chris Adams
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.

2020-07-07 Thread Lennart Poettering
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.

2020-07-07 Thread Peter Robinson
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.

2020-07-07 Thread Gerd Hoffmann
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.

2020-07-06 Thread John M. Harris Jr
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.

2020-07-06 Thread Peter Robinson
> > 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.

2020-07-06 Thread Neal Gompa
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.

2020-07-06 Thread John M. Harris Jr
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.

2020-07-06 Thread Peter Robinson
> > 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.

2020-07-06 Thread Neal Gompa
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.

2020-07-06 Thread John M. Harris Jr
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.

2020-07-06 Thread Hans de Goede

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.

2020-07-06 Thread John M. Harris Jr
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.

2020-07-06 Thread Jóhann B . Guðmundsson

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.

2020-07-06 Thread John M. Harris Jr
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.

2020-07-06 Thread Jóhann B . Guðmundsson

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.

2020-07-06 Thread Christian Stadelmann
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.

2020-07-06 Thread Javier Martinez Canillas
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.

2020-07-06 Thread nickysn
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.

2020-07-06 Thread Nicolas Mailhot via devel

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.

2020-07-06 Thread Gerd Hoffmann
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.

2020-07-06 Thread Simo Sorce
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.

2020-07-06 Thread Nicolas Mailhot via devel
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.

2020-07-06 Thread Gerd Hoffmann
  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.

2020-07-06 Thread Simo Sorce
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.

2020-07-06 Thread Gerd Hoffmann
  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.

2020-07-06 Thread Gerd Hoffmann
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.

2020-07-06 Thread Gerd Hoffmann
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


Re: The future of legacy BIOS support in Fedora.

2020-07-06 Thread nickysn
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.
> 
> > 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 ...
> 
> > 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).

You're right, and that's yet another reason it's not a good idea to use
childish names as "systemd-bloat". I agree that grub2 is more bloated
and that it doesn't make sense to bring all the complexities of BIOS
boot to UEFI. However, the real question is, why does it matter? It's
only a boot loader. It does its job in a fraction of a second and then
it's all done, and the kernel takes it up from there. None of the
"bloated" bootloader code stays in memory. And wasting 2.5 MB instead
of 94 KB of disk space would only matter if we lived in the times when
hard drives were 10 MB or 20 MB :) It's true that the extra complexity
means it's more prone to bugs, but it has already been debugged fairly
well and does its job just fine, so what's the problem?

My real problem with grub2 is not that it's complex, but the fact that
it exposes its complexities to the user. I wish it had an "easy" mode,
where you could configure it easily for the common things that 99% of
the users would do, such as:

1. setting the boot menu timeout
2. choosing the default boot option - e.g. always Fedora, or always
Windows, or always a single entry, or, alternatively, as an option,
remember the last chosen option, and just repeat it, if the timeout
expires - this is invaluable when you dual boot Windows and have to
install Windows updates, because they are notorious for rebooting the
system several times, and you can't always sit in front the computer
for hours, so that you can catch the 5 seconds when the boot menu
appears, so you can choose Windows again. :)
3. changing the kernel boot options
4. adding passwords to certain menu entries

These are common things, that I'm reluctant to do, because I'm put off
by the complexities of grub2 configuration. I wish it had an easy mode
that just covers these common scenarios. I don't want to remove
features from it, I think it's 

Re: The future of legacy BIOS support in Fedora.

2020-07-06 Thread Stephen John Smoogen
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. The assumption being that
you are saying this is what should be a default.. and now you say
there are no downsides. I assume that people are talking past each
other, but in case not, there are always problems

1. Various systems blank out keyboard strokes in case of stuck key. I
have seen this on a lot of servers, workstations and some laptops.
Basically hold a key too short and it gets cleared, hold a key too
long and the system assumes stuck key and ignores keyboard for 30
seconds.
2. Other systems blank out keyboard strokes from before the beginning
of OS boot sections and expect that your OS will give you time to
press some keystrokes before booting. My parents 2 laptops with
different vendors (Dell and ASUS) do that. [They wanted to try what
their son works on... and I found this out while trying to debug
things remotely over the years. We push out bad kernels every now and
then]
3. Some hardware is controlled by things like Serial over LAN (SOL)
which a lot of mgmt ports use. That puts a limit on repeated character
strokes and will break a connection and such. I have spent way too
long this last week dealing with Fedora 30+ systems with short boot
menus over serial over lan and having to power cycle the server (a 3
to 5 minute wait) to get back to the boot menu for one more attempt of
a 2 second keyboard section which SOL may scrub. Trying to debug a
problem over a phone with a parent is similar.
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 can see where a zero timeout is a good thing on hardware which
allows it and if the person is ok with it. It is a complete nightmare
on hardware or remote support.

> > and objectively undiscoverable..
>
> Indeed.  Would be nice to show these hotkeys somewhere.  Extend the
> help line which is shown when you press '?' for example.
>

Again, in a zero boot timeout how would hotkeys be seen? A lot of
systems (even new ones :( ) are still recovering from hardware video
tests with screens flashing and such. If I have an external monitor
hooked up to my laptop, I rarely see the grub menu with a default
timeout.. the screen steadies only by the time the system has reached
the enter a password to decrypt drive.

My issues here are not with sd-boot or grub. It is with assuming that
a fast seen by menu is a good thing by default. I think it would be
great as a config option to shoot yourself in the foot by choice.. but
I spend too much time debugging other people's problems to like it by
default :).


-- 
Stephen J Smoogen.
___
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.

2020-07-06 Thread Tomasz Torcz
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/


-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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.

2020-07-06 Thread Gerd Hoffmann
  Hi,

> I have no problem with GRUB2 or sd-boot. I have much more problems
> with refind and their ilk. While things can look pretty, that's fine,
> as soon as it gets in my way when I try to get things done it stops
> being fine.

"getting into the way" IMO includes "doesn't show up on the serial
console".

Both sd-boot and grub2 are doing fine here, the standard uefi text
console works on both vga and serial line.  Anything doing something
fancy on the framebuffer is problematic here ...

take care,
  Gerd

PS: yes, you can configure grub2 to do fancy graphics, but fedora
doesn't do that by default.
___
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.

2020-07-06 Thread Gerd Hoffmann
  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.

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

> 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


Re: The future of legacy BIOS support in Fedora.

2020-07-06 Thread Jóhann B . Guðmundsson

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.


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.

2020-07-06 Thread Jóhann B . Guðmundsson

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.



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.

2020-07-05 Thread nickysn
On Sun, 2020-07-05 at 11:50 -0700, John M. Harris Jr wrote:
> On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote:
> > On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
> > > Chromebook devices are neither UEFI nor BIOS. You can use GPT
> > > disk layout
> > > while still booting BIOS, which they also don't do. Chromebook
> > > devices
> > > either boot with uboot -> depthcharge or Coreboot -> uboot ->
> > > depthcharge. I don't see how this helps your argument.
> > 
> > If one adds ChromeOS devices into the numbers I posted, then the
> > proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS-
> > only
> > devices on the market (and their portion of the total install base)
> > goes
> > down, not up.
> > 
> > So using the absense of chromebooks in the numbers I referenced
> > actually
> > boosts, rather than undermines, my argument.  Oh, there were
> > supposedly
> > 17 million chromebooks shipped in 2019, versus 261 million "PCs"
> > and
> > 12-ish million "servers".
> > 
> > ...Is this horse sufficiently dead yet?
> > 
> >  - Solomon
> 
> Actually, Coreboot has a SeaBIOS payload as well, so the x86_64
> Chromebooks 
> are "BIOS-boot-capable" systems. (Coreboot also has a GRUB payload,
> which is 
> used by early Purism devices, before they switched to SeaBIOS, and is
> used by 
> all x86_64 Libreboot systems).

I can also confirm that my Acer C720 Chromebook has a SeaBIOS payload,
which is the only way to go, if you want to boot something other than
ChromeOS:

https://www.chromium.org/a/chromium.org/dev/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook#TOC-Legacy-Boot

The default boot method that ChromeOS uses requires the OS to be signed
by Google's private key, which is a secret, so you can't boot Fedora or
any other distro with it. And AFAIK, you can't install other keys,
you're just supposed to use SeaBIOS for other operating systems.

I don't know much about newer chromebooks, though. But I wouldn't be
surprised if they are the same, since Google doesn't have much reason
to adopt UEFI, provided that they control both the software and the
hardware and that they have already developed a system that works.

Btw, this machine is from 2013. I use it for Coreboot+SeaBIOS
experiments.

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.

2020-07-05 Thread John M. Harris Jr
On Sunday, July 5, 2020 12:18:46 PM MST Solomon Peachy wrote:
> On Sat, Jul 04, 2020 at 09:51:30PM -0700, John M. Harris Jr wrote:
> > Many people on this very thread are still using BIOS boot systems, and one
> > person provided a source for a NEW system they're using which is BIOS
> > boot,
> > while another provided factory-default BIOS configurations on hardware
> > supporting UEFI. That's hardly similar the case you're referencing.
> 
> When have I ever said those systems don't exist?  All I've ever said is
> that those systems represent a miniscule (and ever-shrinking) portion of
> the market.
> 
> I'd wager that more 32-bit-only x86 systems are still sold than
> BIOS-boot-only ones, and Fedora already dropped support for the former.
> 
> (btw, You keep mixing up "bios-boot-only" and "bios-boot-capable" --
>  please pick one and stick with it; it'll make your arguments more
>  coherent)

I don't keep mixing them up, but they're similar cases. As mentioned elsewhere 
in the thread, if the vendor disabled UEFI on UEFI-capable systems, the end 
user is likely to leave it that way.

> > It can actually do both, I can dig up the solution that was provided to
> > me,
> > using GRUB2, from the thread where they tried to kill off optical media.
> 
> Does the Fedora installer actually do this, or is it a brittle
> manually-applied hack that could get trashed by anything that wants to
> manipulate the MBR?  (eg gparted)

No, the Fedora installer doesn't create a USB boot entry.. Why would it? It 
was used to chainload the Fedora installer on systems that don't support USB 
boot. Also, it's not a hack. This is just one of the many things GRUB2 
supports. It's a very powerful bootloader.

> (What I did to get around this the last time was to use a small
>  IDE-attached CF card for /boot.  That system used mdraid so it also
>  made for a vastly simpler partitioning layout)
> 
> > Intel has NOT ended support for it. Anyone claiming as much is delusional
> > at best.
> 
> I'm sorry, I'm going to trust Intel's word over yours.

Where has Intel actually published anything saying BIOS boot will no longer be 
available? I can only find articles from 2017, where it was proposed in a 
presentation.

> > > Every one of those shipped Apple and Windows-based systems boots using
> > > UEFI.
> > 
> > That's not the case, as cited earlier in this thread.
> 
> Please actually *read* what I am writing.  That 94% market share
> represents *new systems* *shipped* with Apple or Microsoft operating
> systems.
> 
> Macs have been UEFI-only since 2007, and since 2012 Microsoft has
> required UEFI for systems shipping with Windows 8 (or newer) Thus, every
> one of the 253 million Windows and Mac systems shipped in 2019 were
> booting with UEFI.  Furthermore, starting in November 2016 Microsoft
> disallowed new system sales with Windows 7 (ie the last of the
> non-EFI-required-for-preinstalls version) -- so every system shipped
> with Windows or MacOS in the past *four years* has required use of UEFI.
> (That's more than a *billion* systems!)

That's simply false, that "every system shipped with Windows or MacOS in the 
past *four years* has required use of UEFI." Whether you want to accept it or 
not, vendors are still selling systems with Windows installed with BIOS boot. 
It may be true for MacOS, but that's its own little walled garden. I can't say 
when they started using UEFI, and it doesn't really matter. When a proprietary 
software vendor started using something doesn't have any bearing on what we 
should support in the Fedora project.

> ...Seriously, these are hard facts, and not something up for debate.

See above.

> > Based on what? Are you assuming Linux is only on servers?
> 
> No, as I wrote, I assumed Linux is on all servers and 2% of non-server
> PCs, for a combined total of aobut 6% of 2019 shipped units. The real
> numbers are less than this, as not all servers are shipped with/for
> Linux, and that 2% desktop linux represents the estimated install base
> rather than shipping market share.
> 
> > As cited elsewhere in this thread, most servers, in fact, do have
> > better BIOS support than UEFI support, with some weird quirks.
> 
> You act like there have never been "wierd quirks" with BIOS-based
> systems, especially in the takes-five-minutes-to-get-to-grub server
> realm.

That's not a bug or quirk, some servers just take a long time to do checks 
with their BMC and other internals. It doesn't take 5 minutes, however.

> Vendor firmware bugs are a fact of life.  Some get fixed; most others
> have to be worked around one way or another.

I've not run into a case where using GRUB didn't work around vendor firmware 
bugs related to booting a given system.

> > As well as any small to medium OEM. Most OEMs don't actually care about
> > Windows Certification.
> 
> Anyone selling systems with Windows preinstalled will care, which means
> their suppliers and OEMs will care, because they don't want to get
> locked out of 

Re: The future of legacy BIOS support in Fedora.

2020-07-05 Thread Solomon Peachy
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.

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

2020-07-05 Thread Solomon Peachy
On Sat, Jul 04, 2020 at 09:51:30PM -0700, John M. Harris Jr wrote:
> Many people on this very thread are still using BIOS boot systems, and one
> person provided a source for a NEW system they're using which is BIOS boot,
> while another provided factory-default BIOS configurations on hardware
> supporting UEFI. That's hardly similar the case you're referencing.

When have I ever said those systems don't exist?  All I've ever said is 
that those systems represent a miniscule (and ever-shrinking) portion of 
the market.

I'd wager that more 32-bit-only x86 systems are still sold than 
BIOS-boot-only ones, and Fedora already dropped support for the former.

(btw, You keep mixing up "bios-boot-only" and "bios-boot-capable" -- 
 please pick one and stick with it; it'll make your arguments more 
 coherent)

> It can actually do both, I can dig up the solution that was provided to me,
> using GRUB2, from the thread where they tried to kill off optical media.

Does the Fedora installer actually do this, or is it a brittle 
manually-applied hack that could get trashed by anything that wants to 
manipulate the MBR?  (eg gparted)

(What I did to get around this the last time was to use a small
 IDE-attached CF card for /boot.  That system used mdraid so it also
 made for a vastly simpler partitioning layout)

> Intel has NOT ended support for it. Anyone claiming as much is delusional at
> best.

I'm sorry, I'm going to trust Intel's word over yours.

(Now if Intel has backtracked or changed their plans to "require UEFI 
 class 3 on all client and datacenter platforms by 2020", they've not 
 seemed to have publicly stated that anywhere)

> > Every one of those shipped Apple and Windows-based systems boots using
> > UEFI.
>
> That's not the case, as cited earlier in this thread.

Please actually *read* what I am writing.  That 94% market share 
represents *new systems* *shipped* with Apple or Microsoft operating 
systems.

Macs have been UEFI-only since 2007, and since 2012 Microsoft has 
required UEFI for systems shipping with Windows 8 (or newer) Thus, every 
one of the 253 million Windows and Mac systems shipped in 2019 were 
booting with UEFI.  Furthermore, starting in November 2016 Microsoft 
disallowed new system sales with Windows 7 (ie the last of the 
non-EFI-required-for-preinstalls version) -- so every system shipped 
with Windows or MacOS in the past *four years* has required use of UEFI.  
(That's more than a *billion* systems!)

...Seriously, these are hard facts, and not something up for debate.

> Based on what? Are you assuming Linux is only on servers?

No, as I wrote, I assumed Linux is on all servers and 2% of non-server
PCs, for a combined total of aobut 6% of 2019 shipped units. The real
numbers are less than this, as not all servers are shipped with/for
Linux, and that 2% desktop linux represents the estimated install base
rather than shipping market share.

> As cited elsewhere in this thread, most servers, in fact, do have
> better BIOS support than UEFI support, with some weird quirks.

You act like there have never been "wierd quirks" with BIOS-based 
systems, especially in the takes-five-minutes-to-get-to-grub server 
realm.

Vendor firmware bugs are a fact of life.  Some get fixed; most others 
have to be worked around one way or another.

> As well as any small to medium OEM. Most OEMs don't actually care about
> Windows Certification.

Anyone selling systems with Windows preinstalled will care, which means 
their suppliers and OEMs will care, because they don't want to get 
locked out of the massive market that Windows represents.

(Small Boutique OEMs and embedded/industrial niches notwithstanding, of 
 course.  There's a _very_ long tail of stuff like that.  FFS, look at 
 the diehard Amiga folks..)

> Let's be honest, neither my numbers nor yours even matter in this,
> beyond subjective arguments. If we want to make objective claims based
> on numbers, we'd need to figure out how many Fedora users have systems
> 1) supporting UEFI 2) using UEFI.

Of course.  We need actual numbers if we're to make informed decisions.

Anectdotally, of the sxiteen physical Fedora/CentOS x86 systems I'm 
directly responsible for, all but two support (and also boot from) UEFI. 
I hope to finally re-retire the older of the two in a few weeks, 
replacing it with a machine only half its age.

(There's also a small pile of VMs too, generally used as build hosts or
 for QA-type work.  Nearly all are considered disposable and can be easily
 recreated)

For the record, I think any notion of auto-migrating systems from BIOS 
to UEFI booting is insane.  And any talk of retiring BIOS support in 
Fedora should probably be put off until the F40 timeframe.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature

Re: The future of legacy BIOS support in Fedora.

2020-07-05 Thread Tom Seewald
> BIOS-based systems make up a miniscule minority of the current market.  
> Pretending otherwise is delusional, and delusions are no basis for 
> technical decisions.
> 
>  - Solomon

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.
___
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.

2020-07-05 Thread Chris Murphy
On Sun, Jul 5, 2020 at 12:41 PM Nicolas Mailhot via devel
 wrote:
>
> Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit :
> >
> > specification != standard
>
> I, for one, am very happy that the systemd project makes the effort of
> documenting its formats so others can write competing implementations
> or write software that interacts with the systemd implementation.
>
> That’s several orders of magnitude better than the usual my code is the
> best, copy whatever undocumented thing I did by accident in my last
> commit, this is the reference implementation, I won’t commit to
> anything and I will change it at will without notification in the
> future.
>
> Thank you Lennart for understanding what we meant when we asked you to
> engage with standards like the FHS years ago, and for not embarking
> upon blackbox unspecified coding.
>
> We all hate writing documentation and formal specifications are among
> the most exhausting documentation one may write.
>
> And, nothing wrong with writing a spec for things not specified yet,
> quite the countrary.

Agreed. This is a better response.

Thanks Lennart!


-- 
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


Re: The future of legacy BIOS support in Fedora.

2020-07-05 Thread John M. Harris Jr
On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote:
> On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
> > Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout
> > while still booting BIOS, which they also don't do. Chromebook devices
> > either boot with uboot -> depthcharge or Coreboot -> uboot ->
> > depthcharge. I don't see how this helps your argument.
> 
> If one adds ChromeOS devices into the numbers I posted, then the
> proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS-only
> devices on the market (and their portion of the total install base) goes
> down, not up.
> 
> So using the absense of chromebooks in the numbers I referenced actually
> boosts, rather than undermines, my argument.  Oh, there were supposedly
> 17 million chromebooks shipped in 2019, versus 261 million "PCs" and
> 12-ish million "servers".
> 
> ...Is this horse sufficiently dead yet?
> 
>  - Solomon

Actually, Coreboot has a SeaBIOS payload as well, so the x86_64 Chromebooks 
are "BIOS-boot-capable" systems. (Coreboot also has a GRUB payload, which is 
used by early Purism devices, before they switched to SeaBIOS, and is used by 
all x86_64 Libreboot systems).

People are still using systems from before 2019. More importantly, people are 
still using systems from 2010-2012 in Fedora, as demonstrated by this thread.

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

2020-07-05 Thread Nicolas Mailhot via devel
Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit :
> 
> specification != standard

I, for one, am very happy that the systemd project makes the effort of
documenting its formats so others can write competing implementations
or write software that interacts with the systemd implementation.

That’s several orders of magnitude better than the usual my code is the
best, copy whatever undocumented thing I did by accident in my last
commit, this is the reference implementation, I won’t commit to
anything and I will change it at will without notification in the
future.

Thank you Lennart for understanding what we meant when we asked you to
engage with standards like the FHS years ago, and for not embarking
upon blackbox unspecified coding.

We all hate writing documentation and formal specifications are among
the most exhausting documentation one may write.

And, nothing wrong with writing a spec for things not specified yet,
quite the countrary.

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.

2020-07-05 Thread Javier Martinez Canillas
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).

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.

2020-07-05 Thread Solomon Peachy
On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
> Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout 
> while still booting BIOS, which they also don't do. Chromebook devices either 
> boot with uboot -> depthcharge or Coreboot -> uboot -> depthcharge. I don't 
> see how this helps your argument.

If one adds ChromeOS devices into the numbers I posted, then the 
proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS-only 
devices on the market (and their portion of the total install base) goes 
down, not up.

So using the absense of chromebooks in the numbers I referenced actually 
boosts, rather than undermines, my argument.  Oh, there were supposedly 
17 million chromebooks shipped in 2019, versus 261 million "PCs" and 
12-ish million "servers".

...Is this horse sufficiently dead yet?

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

2020-07-05 Thread Chris Murphy
On Sun, Jul 5, 2020 at 11:26 AM John M. Harris Jr  wrote:
>
> On Sunday, July 5, 2020 3:07:44 AM MST Lennart Poettering wrote:
> > On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote:
> >
> >
> > > That systemd throws some crap out doesn't make it a standard. There's no
> > > reason for GRUB to adopt this, or for anyone else to use this.
> >
> >
> > "bloat", "crap", …
> >
> > I am sorry, but you are apparently just a troll and this is the point
> > where I will now ignore you.
> >
> > Just stop being so awful and dismissive, this is not constructive.
>
> Lennart,
>
> This behavior, which is identical to what has drawn attention to your handling
> of GitHub issues recently, simply dismissing them as trolls or conspiracy
> theorists, is why I'm saying that. systemd is not a standards body. It's an
> init system.

specification != standard

You're calling it something it doesn't claim to be and then criticizing it.


-- 
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


Re: The future of legacy BIOS support in Fedora.

2020-07-05 Thread John M. Harris Jr
On Sunday, July 5, 2020 8:12:33 AM MST Markus Larsson wrote:
> I have no problem with GRUB2 or sd-boot. I have much more problems with
> refind and their ilk. While things can look pretty, that's fine, as soon as
> it gets in my way when I try to get things done it stops being fine.

I don't think there's anything visually wrong with systemd-boot, so long as 
it's showing a menu like gummiboot did.

> As I said earlier, I have no problems with sd-boot or the looks of it (it
> seems that is what we are discussing now). I see no real problems with
> using it as default for EFI systems. That's just an opinion though. It does
> what it does and shows what is needed.

Actually, it doesn't do enough to be able to actually boot Fedora systems. 
Please note that full disk encryption is a supported scenario in Fedora, as is 
encrypted /boot or /boot on Btrfs. systemd-boot is not capable of getting 
bootloader configuration files in this case, so your system will never boot.

As for making it the default, I can't see any reason to do that. Standardizing 
on the best bootloader seems like the safe bet, i.e. use GRUB2 everywhere 
possible, and support boot from u-boot, zipl, petitboot, etc. where it's not 
available.

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

2020-07-05 Thread John M. Harris Jr
On Sunday, July 5, 2020 3:07:44 AM MST Lennart Poettering wrote:
> On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote:
> 
> 
> > That systemd throws some crap out doesn't make it a standard. There's no
> > reason for GRUB to adopt this, or for anyone else to use this.
> 
> 
> "bloat", "crap", …
> 
> I am sorry, but you are apparently just a troll and this is the point
> where I will now ignore you.
> 
> Just stop being so awful and dismissive, this is not constructive.

Lennart,

This behavior, which is identical to what has drawn attention to your handling 
of GitHub issues recently, simply dismissing them as trolls or conspiracy 
theorists, is why I'm saying that. systemd is not a standards body. It's an 
init system.

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

2020-07-05 Thread John M. Harris Jr
On Sunday, July 5, 2020 6:18:50 AM MST Solomon Peachy wrote:
> On Sun, Jul 05, 2020 at 08:52:12AM +0200, Nicolas Mailhot via devel wrote:
> > So you want to discuss Linux desktop deployments, excluding the only
> > sucessful mass Linux desktop deployment to date? Why?
> 
> Because the raw data I had access to excludes chromebooks, only listing
> "traditional" PCs and servers.  They lumped chromebooks in with tablets
> and other such things, and I'm not going to spend several thousand
> dollars to buy market reports just for a stupid thread on fedora-devel.
> 
> Additionally, all chromebooks boot with u-boot on top of a UEFI/GPT disk
> layout.  The x86 ones supposedly use coreboot to load u-boot:
> 
>   https://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format
> 
> Needless to say, this actually *helps* my argument, as including
> ChromeOS systems into those numbers will further decrease the overall
> BIOS-capable (and thus, BIOS-only) market share.

Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout 
while still booting BIOS, which they also don't do. Chromebook devices either 
boot with uboot -> depthcharge or Coreboot -> uboot -> depthcharge. I don't 
see how this helps your argument.

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

2020-07-05 Thread Stephen John Smoogen
On Sun, 5 Jul 2020 at 11:23, Markus Larsson  wrote:
>
>
>
> On 5 July 2020 16:27:07 CEST, Stephen John Smoogen  wrote:
> >On Sat, 4 Jul 2020 at 11:34, Neal Gompa  wrote:
> >>
> >> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering  
> >> wrote:
> >> >
> >> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote:
> >> >

> >
> >There is a very different car from what a gear head will design from a
> >person who wants to enjoy driving their car. A gear head will want an
> >easy to fix car with very few things hard to get to. The problem is
> >that usually makes the vehicle noisy, uncomfortable and ugly. The
> >majority of car drivers want something where all those parts are
> >nicely hidden because they like a quiet smooth ride. The same is with
> >computers.. If we want to be able to work on the computers we want a
> >lot of places we can get into the deep internals and mess around. If
> >we want to use the computer day to day without needing to spend 10
> >years learning how to take it apart and put it together.. We want
> >something completely different. In the end, the vast majority of
> >people want things which are hidden away and just do the thing they
> >are supposed to do.. we computer grease monkeys just need to charge
> >more to work on them.
>
> There's no reason there can't be a glossy front hiding what techs really 
> wants. Just look at the bootsplash. Looks pretty but just push a button and 
> you will get actual useful data instead, everybody wins.
> That said, I don't think you are wrong per se. I just think there can we can 
> coexist with the help of smart solutions.
>

Usually the only time I deal with the bootsplash is when the system is
broken in a way that hitting a key won't remove it... so I end up
removing rhgb/quiet and other things. The fact that I can do that is
all I care about.. I get grumpy when proposals want to make that
impossible to be done for whatever reasons. Especially since I will
somehow have to fix it when it breaks but have to get an arc welder to
cut open parts first.

That said, I am not against sd-boot, btrfs, nano or a bunch of other
changes which seem to have gotten every 'stop the change' advocate out
there. I understand a little of where they are coming from... fixing
things are hard enough at times. I also understand what it is like to
be overloaded with everything going on these days and just want things
to stop for a bit. The problem is that doesn't happen, and it
definitely doesn't happen in Fedora. If people need a slower or
stopped OS, there is CentOS or Debian Stable. Fedora isn't as bleeding
edge as other Linux distributions... but it is constantly moving and
it is always going to be a bumpy road.

> As I said earlier, I have no problems with sd-boot or the looks of it (it 
> seems that is what we are discussing now). I see no real problems with using 
> it as default for EFI systems. That's just an opinion though. It does what it 
> does and shows what is needed.
> As for keeping BIOS, yes of course but that seems settled 100 mails ago :)
> I generally argue that I want Fedora to run on as much different things as 
> possible and devices and motherboards with defective UEFI or no UEFI will be 
> here for a while.
>
> M
>
> >
> >
> ___
> 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



-- 
Stephen J Smoogen.
___
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.

2020-07-05 Thread Markus Larsson


On 5 July 2020 16:27:07 CEST, Stephen John Smoogen  wrote:
>On Sat, 4 Jul 2020 at 11:34, Neal Gompa  wrote:
>>
>> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering  
>> wrote:
>> >
>> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote:
>> >
>> > > The user-interactive portion of sd-boot is *awful*. I know our GRUB
>> > > looks ugly by default these days too, but it doesn't have to be, and
>> > > most distros actually do make it look semi-decent.
>> >
>> > BTW, the current look of systemd-boot was proposed by some GNOME
>> > designers back in the day. We just implemented what they wanted.
>> >
>>
>> Now I'm even less surprised. It was probably designed with the idea
>> that it would never be seen. If any designer people actually wanted to
>> make a good boot manager experience, they should take cues from
>> Windows, macOS, or even rEFInd.
>>
>>
>
>It was probably designed on that idea by people who don't spend as
>much time staring at bootloaders as they do operating systems. For the
>overwhelming majority of people using computers they are not going to
>spend a lot of time making choices in a bootloader or things like
>that. For system administrators and operating system developers.. that
>is not the case. For most of the computers I manage, I never actually
>log onto them UNLESS I am going to be dealing with the boot loader. So
>of course the UI is going to be very important to me and I want it to
>do a lot of things it probably shouldn't. Mainly because if I have
>been called to deal with said computer, something has gone very wrong
>and I am going to be trying to make it right.

I have no problem with GRUB2 or sd-boot. I have much more problems with refind 
and their ilk. While things can look pretty, that's fine, as soon as it gets in 
my way when I try to get things done it stops being fine.

>
>There is a very different car from what a gear head will design from a
>person who wants to enjoy driving their car. A gear head will want an
>easy to fix car with very few things hard to get to. The problem is
>that usually makes the vehicle noisy, uncomfortable and ugly. The
>majority of car drivers want something where all those parts are
>nicely hidden because they like a quiet smooth ride. The same is with
>computers.. If we want to be able to work on the computers we want a
>lot of places we can get into the deep internals and mess around. If
>we want to use the computer day to day without needing to spend 10
>years learning how to take it apart and put it together.. We want
>something completely different. In the end, the vast majority of
>people want things which are hidden away and just do the thing they
>are supposed to do.. we computer grease monkeys just need to charge
>more to work on them.

There's no reason there can't be a glossy front hiding what techs really wants. 
Just look at the bootsplash. Looks pretty but just push a button and you will 
get actual useful data instead, everybody wins.
That said, I don't think you are wrong per se. I just think there can we can 
coexist with the help of smart solutions.

As I said earlier, I have no problems with sd-boot or the looks of it (it seems 
that is what we are discussing now). I see no real problems with using it as 
default for EFI systems. That's just an opinion though. It does what it does 
and shows what is needed.
As for keeping BIOS, yes of course but that seems settled 100 mails ago :)
I generally argue that I want Fedora to run on as much different things as 
possible and devices and motherboards with defective UEFI or no UEFI will be 
here for a while.

M

>
>
___
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.

2020-07-05 Thread Stephen John Smoogen
On Sat, 4 Jul 2020 at 11:34, Neal Gompa  wrote:
>
> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering  
> wrote:
> >
> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > The user-interactive portion of sd-boot is *awful*. I know our GRUB
> > > looks ugly by default these days too, but it doesn't have to be, and
> > > most distros actually do make it look semi-decent.
> >
> > BTW, the current look of systemd-boot was proposed by some GNOME
> > designers back in the day. We just implemented what they wanted.
> >
>
> Now I'm even less surprised. It was probably designed with the idea
> that it would never be seen. If any designer people actually wanted to
> make a good boot manager experience, they should take cues from
> Windows, macOS, or even rEFInd.
>
>

It was probably designed on that idea by people who don't spend as
much time staring at bootloaders as they do operating systems. For the
overwhelming majority of people using computers they are not going to
spend a lot of time making choices in a bootloader or things like
that. For system administrators and operating system developers.. that
is not the case. For most of the computers I manage, I never actually
log onto them UNLESS I am going to be dealing with the boot loader. So
of course the UI is going to be very important to me and I want it to
do a lot of things it probably shouldn't. Mainly because if I have
been called to deal with said computer, something has gone very wrong
and I am going to be trying to make it right.

There is a very different car from what a gear head will design from a
person who wants to enjoy driving their car. A gear head will want an
easy to fix car with very few things hard to get to. The problem is
that usually makes the vehicle noisy, uncomfortable and ugly. The
majority of car drivers want something where all those parts are
nicely hidden because they like a quiet smooth ride. The same is with
computers.. If we want to be able to work on the computers we want a
lot of places we can get into the deep internals and mess around. If
we want to use the computer day to day without needing to spend 10
years learning how to take it apart and put it together.. We want
something completely different. In the end, the vast majority of
people want things which are hidden away and just do the thing they
are supposed to do.. we computer grease monkeys just need to charge
more to work on them.


-- 
Stephen J Smoogen.
___
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.

2020-07-05 Thread Solomon Peachy
On Sun, Jul 05, 2020 at 08:41:16AM +0200, Nicolas Mailhot via devel wrote:
> Those things are not meant to run ancient software. They are meant to
> run a very long time. And yes at the end of this time the software is
> ancient. 

Of course.

> That does not mean it is ancient at the start of the system lifecycle

If the new embeded or industrial-type system being deployed is BIOS-only 
(you know, the entire point of this silly thread) then its underlying 
hardware platform (and the software running on top of it) is nowhere 
near the start of its lifecycle, ie it's relatively "ancient".

(See my ealier point about Intel continuing to produce 80386 and 80486 
 CPUs until 2007)

(In 2011 the folks I worked for purchased a brand-new bit of kit for 
 their PCB production line.  The system booted up into Windows NT4, 
 which had been completely EOL'd in 2004, because it used custom 
 hardware that relied on drivers that didn't run on anything newer. This 
 same line had a reflow oven powered by a 386 running DOS..)

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

2020-07-05 Thread Sumit Bhardwaj
I don't know about how important EFI and reducing the bootloader technical debt 
is for the project, but at least for me personally, it will be a straight way 
out. My hard disk has a traditional MBR based structure with about a TB of very 
important data. I don't know of a 100% reliable way of converting it to GPT. 
While I do have backup for most important files, not everything is backed up 
nor do I have means to do so.

The system works perfectly fine for me and I see no reason why I should opt for 
EFI. What is the value add for me, at least till I don't upgrade to a newer 
system? which I won't be at least for next 2 years. So forcing such a 
no-value-add change to existing user will drive them away. At least I would opt 
for a different distro in such case even though it's not something I want to do.

I feel the better approach would be to use it as default for new installations, 
if the disks are appropriately formatted or are empty at the time of 
installation. Else a fall back to grub should be transparently done.

Just my 2 cents from a user's perspective.
___
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.

2020-07-05 Thread Solomon Peachy
On Sun, Jul 05, 2020 at 08:52:12AM +0200, Nicolas Mailhot via devel wrote:
> So you want to discuss Linux desktop deployments, excluding the only
> sucessful mass Linux desktop deployment to date? Why?

Because the raw data I had access to excludes chromebooks, only listing 
"traditional" PCs and servers.  They lumped chromebooks in with tablets 
and other such things, and I'm not going to spend several thousand 
dollars to buy market reports just for a stupid thread on fedora-devel.

Additionally, all chromebooks boot with u-boot on top of a UEFI/GPT disk 
layout.  The x86 ones supposedly use coreboot to load u-boot:

  https://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format

Needless to say, this actually *helps* my argument, as including 
ChromeOS systems into those numbers will further decrease the overall 
BIOS-capable (and thus, BIOS-only) market share.

> Also your data conflates systems sold in  with systems in use in
> . 

No, it does not; these commercial market report previews I used cover 
revenue and units shipped in 2019, not total install base.  (those are 
also available, but I'm not going to fork over several thousand dollars 
over a stupid fedora-devel thread)

That said, I did deliberately conflate the two in one place -- I used 
the "2%" linux desktop install base as a proxy for "market share", but 
acknowledged that, and assigned those numbers to the "BIOS" side.

If someone has numbers that show the actual install base of in-use 
BIOS-boot and BIOS-only systems, I'd love to see them.  And I'll gladly 
donate the contents of my wallet to the EFF if the BIOS numbers are 
still growing in absolute terms -- ie new systems being deployed faster 
than old ones are retired.

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

2020-07-05 Thread Lennart Poettering
On Sa, 04.07.20 12:49, Chris Murphy (li...@colorremedies.com) wrote:

> Why do the security folks want POSIX and SELinux labels on the
> contents of /boot? I've never really gotten a straight answer on this,
> but I know it's considered important and a sticking point for why some
> folks do not want the kernel and initramfs and bootloader
> configuration files on FAT. And can it be mitigated some other way?
> Maybe not persistently mounting /boot and /boot/efi or mounting them
> on-demand elsewhere only when they need to be modified?

You can assign an SELinux label onto a whole file system at mount time
via the context= mount option and related ones. Hence the question is
why it is supposedly so essential to be able to label the initrd
differently than the kernel itself...

Note that systemd can automatically mount the ESP and XBOOTLDR
partition for you if you let it. If done so it will set it up via
automounts, so that the file systems are:

1) automatically fsck'ed on first mount
2) only mounted when actually accessed
3) very quickly after the last access unmounted again

This should provide the best data integrity guarantees on those file
systems as the file system is almost always unmounted, and thus in a
clean state, and automatically fixed in the unlikely case that the
system was turned off right at the moment the fs was accessed.

Note that this mechanism is independent of the boot loader spec, or
sd-boot or anything like that. It's automatically used if /boot or
/efi are not listed in /etc/fstab and if partitions of the right type
are found in the partition table.

(Note that this automatism doesn't support /boot/efi/, first of al
because it's weird, but mostly because in order to establish the
second automount point we'd have to activate the first one, which
defeats the whole excercise of having file systems that are never
mounted, except if they are accessed)

Hence, a couple of changes independent of the sd-boot/grub/boot loader spec
situation would make a lot of sense for Fedora:

1) Use the XBOOTLDR uuid for /boot
2) Mount ESP to /efi instead of /boot/efi (you can keep a symlink in
   /boot/efi/ if you like)
3) Drop generation of ESP and /boot entries in /etc/fstab in the
   installer, and let the automatic logic do its thing.

> There are other use cases folks are interested in. Here's one:
> https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Boot_on_Btrfs

You know using a journalling file system on /boot means means you
drastically complicate things if you want to implement boot counting,
because then you need a writable fs, and then things become complex
because you need a ful fs implementation in grub.

Do the btrfs upstream folks commit to support an alternative writable
btrfs implementation in grub? I doubt so?

> That aims to make it possible to support a snapshot/rollback regime.
> There needs to be a way to pair the states of /boot and / so that the
> kernel we're using to boot a rollback, has modules available on the
> rolledback /usr. That does not need to be done with Btrfs, even
> though

You are just reimplementing OSTree/Atomic/FedoraCoreOS with that...

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.

2020-07-05 Thread Lennart Poettering
On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote:

> That systemd throws some crap out doesn't make it a standard. There's no
> reason for GRUB to adopt this, or for anyone else to use this.

"bloat", "crap", …

I am sorry, but you are apparently just a troll and this is the point
where I will now ignore you.

Just stop being so awful and dismissive, this is not constructive.

Thank you,

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.

2020-07-05 Thread John M. Harris Jr
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.

Additionally, the theoretical proposal discussed earlier in the thread was to 
add it as an alternate option, which users could ELECT to trying out, not to 
make it the default bootloader. Probably because it doesn't meet the needs of 
actually being able to boot Fedora systems.

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

2020-07-05 Thread Luya Tshimbalanga
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.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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.

2020-07-05 Thread Nicolas Mailhot via devel
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit :
> (Note this explicitly excludes Chromebooks) 

So you want to discuss Linux desktop deployments, excluding the only
sucessful mass Linux desktop deployment to date? Why?

Also your data conflates systems sold in  with systems in use in
. That’s a very misleading assumption to make, computer systems
have matured a lot, and hardware lifetime has gone up with this
maturing (much to manufacturer’s despair, the maturing is starting to
affect smartphones now).

It’s no longer early days when you replaced last year’s experimental
system with current year’s experimentalk system because nothing had
settled yet.

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.

2020-07-05 Thread Nicolas Mailhot via devel
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit :
>  folks that make very long-lifecycle industrial systems 
> meant to run generally ancient software

Those things are not meant to run ancient software. They are meant to
run a very long time. And yes at the end of this time the software is
ancient. That does not mean it is ancient at the start of the system
lifecycle (I’ve seen crazy people building such systems from a Fedora
image, because they knew they would accumulate enough technical debt
during the system lifecycle, without taking the centos debt from the
start up)

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.

2020-07-04 Thread John M. Harris Jr
On Saturday, July 4, 2020 8:10:49 PM MST Solomon Peachy wrote:
> On Sat, Jul 04, 2020 at 05:24:05PM -0700, John M. Harris Jr 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.
> 
> Lots of hardware has a very long tail -- For example, Intel didn't
> actually stop making the 80386 and 80486 until late 2007, yet Fedora
> never ran on anything older than the original Pentium, which was a full
> decade old when FC1 landed in 2003.

Many people on this very thread are still using BIOS boot systems, and one 
person provided a source for a NEW system they're using which is BIOS boot, 
while another provided factory-default BIOS configurations on hardware 
supporting UEFI. That's hardly similar the case you're referencing.

> > There is no 2TB upper limit on drive sizes as a result of booting from
> > BIOS.
> 
> I still have two BIOS-only systems in production that can't handle a
> _boot_ drive over 2TB in size.  (They also can't boot off of USB sticks)

It can actually do both, I can dig up the solution that was provided to me, 
using GRUB2, from the thread where they tried to kill off optical media.

> > 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.
> 
> Of course folks can use use GPT partitioning with BIOS; they just can't
> boot off of it.

You can boot off of it, so long as you're using GRUB2. GRUB2 loads from MBR, 
parses the GPT, and boom, 2TB or larger partitions on BIOS.

> 
> > Why do you "despise" BIOS boot?
> 
> There are better, simpler booting mechanisms that don't require
> emulating the behavior (and working around the limitations) of the
> 40-year-old original IBM PC and the even-older i8086.

> No matter how you or I feel about legacy BIOS booting, Intel has ended
> support for it, so Fedora *must* be ready for a UEFI-only future.  We
> can no longer tell folks "just revert to BIOS boot to fix problem X"

Intel has NOT ended support for it. Anyone claiming as much is delusional at 
best. We can continue to tell people "just revert to BIOS boot to fix problem 
X" or "Disable Secure Boot to fix problem Y". Fedora is already fine on 
systems that only support UEFI, using GRUB2 UEFI.

> (But at the same time Fedora has to continue to support BIOS booting for
>  the forseable future, because there's still a considerable install base
>  of BIOS-boot systems)

Yes, and there will be for decades to come. BIOS isn't going away any time 
soon, just like broken EFI implementations aren't going away.

> > > BIOS-based systems make up a miniscule minority of the current market.
> > > Pretending otherwise is delusional, and delusions are no basis for
> > > technical decisions.
> > 
> > That's absolutely false, as demonstrated elsewhere in this thread.
> > Pretending otherwise is delusional, and delusions are no basis for
> > technical decisions.
> 
> I have hard data to back up my assertions.  What do you have?

Please read this thread before replying. I've had to repeat myself on this 
several times now, as have others.

> Fine, I'll show my work.
> 
> There were 260-odd-million "PCs" shipped in 2019, and about another 12
> million physical servers, according to IDC.  (Note this explicitly
> excludes Chromebooks) For simplicty's sake, let's assume all servers run
> Linux, along with a generous 2% of the desktop market.  This leaves
> Apple and Windows with about 94% of the 2019 market.
> 
> Every one of those shipped Apple and Windows-based systems boots using
> UEFI. 

That's not the case, as cited earlier in this thread.

> Even if we (falsely) assume that every single linux system boots
> using BIOS instead of UEFI, that means that in 2019, BIOS-booting
> systems make up *at most* 6% of the market.

Based on what? Are you assuming Linux is only on servers? As cited elsewhere 
in this thread, most servers, in fact, do have better BIOS support than UEFI 
support, with some weird quirks. If you're interested, I could give you some 
interesting stories about Dell's current generation PowerEdge servers, which 
have some BIOS/UEFI weirdness going on. They're BIOS boot by default, and will 
*then* load the EFI framework if you've enabled EFI, or try to load one of the 
vendor apps.

> Mind you, that's BIOS-booting, not BIOS-only.  The actual BIOS-only
> numbers will be *much* smaller, for the simple reason that OEMs
> generally need to have their hardware able to pass Windows
> Certification, which means the presence of full UEFI, even on servers.
> 
> The ones that don't care about Windows certification are boutique OEMs
> like System76 and folks that make very long-lifecycle industrial systems
> meant to run generally ancient software, neither of which ship in any
> appreciable volume compared to general-purpose desktops and laptops.

As well 

  1   2   3   >