Messages

How usable is the UEFI build at this point?

You can decide for yourself by looking at test results here and reading issue reports here. Feel free to let us know how to make our offering better. We are still working on Dasharo (coreboot+SeaBIOS) based on coreboot 24.02.01 and how to publish it this quarter.

Hi all,
I have some news for you. After struggling with the initial campaign to revive PC Engines firmware builds, we finally gathered funds and created a sustainable business model for our famous hardware. We recently released the first version of Dasharo for PC Engines with UEFI support. Feel free to check it out

Please let us know what you think about it.

P.S. In the background, we are working on continuing the old version of the code, which we call Dasharo (coreboot+SeaBIOS). We plan to support both the mainline and legacy versions. Information about that endeavor can be found here

Hello everyone,
We want to express our deepest gratitude to all respondents who took the time to complete our survey. Your valuable feedback has contributed significantly to understanding the community's needs and preferences. We have closed the survey and are excited to share a summary and some results with you.

We cordially invite you to attend the Dasharo User Group meeting, where we will present the survey findings. Your participation in the mini-conference will provide insights into the community's opinions and help shape the future of our firmware solutions.

For more information about the event and to register (not required), please visit: https://vpub.dasharo.com/e/1/dasharo-user-group-1

Once again, thank you for your contribution, and we look forward to seeing you at the Dasharo User Group #1 meeting!

Best regards,
Piotr Król

@tillsense, thank you.

Announcement was published in BIOS thread.

Dear OPNsense community members,
We regret to announce that PC Engines, a provider of small and low-power servers for network security, wireless networking, and embedded applications, has discontinued its sponsorship for open-source firmware. Although this is a significant change for the open-source firmware community, our commitment to supporting the hardware remains strong. At Dasharo, we aim to continue the legacy of PC Engines by distributing open-source firmware and putting the community's needs first. Our focus will be on releases and feature sets driven by community support. We are considering a subscription model to ensure stable and reliable firmware updates. Your input is important to us, and we would appreciate your feedback through our survey. Please help us understand how we can better serve the open-source firmware community and ensure its success in the future.

Full details: https://docs.dasharo.com/variants/pc_engines/post-eol-fw-announcement

Official statement will be published this week.

It is not only miczyg, but whole 3mdeb team stopped work on PC Engines. We hope to have some announcements about the reasons for slow down and explain what would be the path forward in upcoming announcements.

We are also interested in this topic and working on that to present at PSEC 2019. If anyone has experience please let us know. What we facing right now is lack of network connection in VM. OPNsense installed as it should and vif seem to be visible by OS.

First sorry for a long time between my replies. I have no other excuses then saying we working to deploy open-source firmware for more firewall devices.

What is the goal for coreboot? I own a Protectli FW4B and love it. Great device...small is stature but very powerful.

Main goals are described here. In this case we have couple improvments:

• long term maintainability - firmware is open and even when the vendor will have a problem getting firmware updates community can take over, it is also easier to fix open code then binary blob :)
• reproducible builds - we can check if our firmware was not changed in a malicious way
• customization - devices can be customized
• auditability - you can read most of the code that devices use for boot process

Probably many more, but those are some key points.

How does this run on board with Intel BootGuard enabled?

Protectli doesn't ship Intel Boot Guard enabled platforms. Where did you get one? BTW to workaround Intel Boot Guard you need exploit for it and even then what you can do with firmware is limited.

@tillsense,
thanks for that topic. I'm very interested in getting more replies. At some point, I did the research and found some Netgate obsolete devices:

https://www.netgate.com/support/product-lifecycle.html  - looks like some RCC-VE have coreboot integration.

Of course, my assumption is that pfSense devices would support OPNsense, but I may be wrong.

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.

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.

@tillsense,
sorry for not replying for quite long. We are very busy with work for Protectli and adding products to our shop which will ship in the area of EU. Of course, we selling FW2B and FW4B with coreboot as an option - more information here. We are open for extensions recommendations.

I have 2 updates:
1. Source code for Protectli FW2B and FW4B is under review: https://review.coreboot.org/c/coreboot/+/32076 - depending on skill set this code can be built and flashed. The code was validated to work with OPNsense.
2. We started work on FW6A/B/C which are based on Kaby Lake. Results of our work should be pushed to the community in Q2 2019.

If you see anything missing feel free to ask.

Because Protectli representatives see value in Open Source Firmware for their customers.

Have you got any suggestions about other hardware platforms for which porting to Open Source Firmware would benefit OPN sense community? TBH creating reasonable selection criteria is beyond 3mdeb at this point - we are not professional network appliance experts, but we are pretty sure that correct firmware support can bring benefits to network appliance world.