Feature request: UEFI compatible Installation of Serial Image

[karl047]

Hi,
it will be nice, when the serial Image of the next major update works with UEFI too, like the VGA Version.

regards,
karl

[franco]

That may be something to be done indeed. The question is if all serial hardware, mostly embedded and or older varieties are ok with this. I will try to provide a test image for this when I have a bit of time.


Cheers,
Franco

[karl047]

Thank you, when you want I can test it later 

[skyjam]

I'm interested aswell

Current appliances should all support UEFI...

[pietrushnic]

0.02$ from Open Source Firmware perspective:

• What problem are we trying to solve here? My feeling is that forcing everyone to use UEFI cause more problems then it solves. If the only value is working VGA/HDMI or other videos output, we should probably ask our selves if cause not lays in closed source nature of provided firmware. Going further, if this is OS responsibility to address those problems? I know that UEFI starting to be de-facto standard, but it would be great if that feature request would not cause problems to users that want to promote open source firmware and buy from hardware vendors that support that approach e.g. PC Engines and Protectli. So maybe to keep both sides happy there is a need for both UEFI and legacy version of the system?
• It is up to hardware vendors if they want to sell hardware, which is UEFI compatible. It is probably very easy if we consider closed source firmware, which is typically sold by the offshore manufacturer as part of the hardware. Security and quality of that closed firmware are very questionable. If anyone knows network appliance hardware with good support for UEFI compatible firmware please let me know. Of course, closed source firmware is not my story, so I would recommend open source firmware. Having UEFI compatible open source firmware is a very complex topic. First, it is expensive to develop and even impossible for some platforms (assuming current market state). Independent BIOS Vendors have long-lasting agreements with silicon vendors and because of that development on their side is cheaper and easier, but they target hardware that ships in a huge volume that's why silicon vendors care. Open source firmware development companies typically rely on reverse engineering. This state should change since there are signs from big silicon vendors that they want to open ecosystem - we will see. So first let's convince hardware vendors. Second, even if there will be a real need for that support keeping everything up to date and according to spec is non-zero effort work. What UEFI spec we should comply to? Who will test that, on which hardware and with which version of firmware? Do we have resources to keep up with UEFI spec? What features we want to support?
  
• What stack of open source firmware should be chosen? For PC Engines we started working on UEFI compliant environment over 2 years ago and presented the state of our work here, the stack was coreboot -> Tianocore payload (UEFI) -> UEFI-aware bootloader -> UEFI-aware OS. We will continue that work and if there is interest in hackers community I can schedule some blog post how to use UEFI support on PC Engines. Over 3 years of maintaining PC Engines firmware we received maybe 5 inquiries with interest in UEFI compatible firmware - almost all from non-commercial entities. Another software stack could be to write everything in edk2 (UEFI implementation), but that means the implementation of drivers in edk2, what can be very expensive and truly will mimic already existing closed source firmware. The last thing that we have to evaluate e.g. for Protectli FW6x (KabyLake) is the behavior of edk2+FSP, if this would be good enough to boot an OS, then maybe it is worth to go that path.
  

Personally, I like Qubes OS approach to the topic. They support both boot modes legacy and UEFI, but to get their certification you have to use open source firmware like coreboot.

[franco]

Well, it would be dual boot like we have now for DVD and VGA. I am only worried about backwards-compatibility with legacy devices, especially serial ones can be older and receive less care or development in general.

@pietrushnic since you are a man of the subject: Do you see this as a real world issue? Could you help assess impact with a provided test image?


Cheers,
Franco

[pietrushnic]

Hi Franco,
we maintain PC Engines and Protectli. Both operate over serial, but second has also HDMI option. I think both should still have serial installation support since removing it will completely break the flow for some integrators. I'm not sure what other hardware platforms you have in mind and it would be great if you can provide the name.

In 3mdeb we can asses impact on PC Engines and Protectli and maybe some other hardware (I will have to check that). If you switch to UEFI without legacy support, then it definitely will be a problem since PC Engines doesn't have UEFI and there are no clear plans for that (we will try to provide something with v4.9.0.6 but before that, it is hard to say). coreboot based platforms will not switch to UEFI payload easily.

What I can say is that I would like to spread Open Source Firmware support starting with most popular network appliance devices that support OPNsense - maybe I should open a thread with some survey about that? If we can have more reliable firmware vendors behind an open implementation, then there should be fewer issues since finally, someone can fix a bug on the firmware side and no weird workarounds on OS side would be needed to make things work.

To be honest, I'm not sure how to correctly handle/implement legacy and UEFI support in BSD systems, but we are willing to fix any problems caused by firmware if dual boot (legacy/UEFI) support will be implemented.