pietrushnic

A summary of the upcoming UEFI capsule updates, exploring areas that were in need of improvement and what has actually been done. The developments affect general usage and documentation, provide strong security guarantees, and enhance feedback during firmware updates. Additionally, a related subject of fwupd as a capsule delivery mechanism on FreeBSD, Qubes OS and Windows is also covered.

3mdeb’s latest Dasharo builds finally let you touch CPU and memory voltages from an open-source BIOS. The release notes are refreshingly blunt about what happens next.

The latest Dasharo firmware release for MSI PRO Z690-A (v1.1.7) and MSI PRO Z790-P (v0.9.5) is here. This release brings preliminary SMI Transfer Monitor support, a new Platform Setup Menu with experimental CPU overclocking options, XMP improvements, and many other fixes and enhancements.

A look at DRTM on ARM: where it stands compared to Intel TXT/AMD SKINIT and what will it take to run TrenchBoot on AArch64. How can TrenchBoot support both x86 and ARM architectures at the same time.

"Long story short, the Dasharo performance led to effectively the same performance as the default proprietary BIOS performance overall. No overall loss in performance in going for the AMD openSIL / open-source option."

This report details a release engineering incident where a Dasharo firmware update successfully performed End-of-Manufacturing (EOM) fusing on NovaCustom laptops but utilized an ephemeral testing key instead of the persistent production key. We provide a technical analysis of the situation and outline impact for affected end users.

This is a post about the process of porting Dasharo to a modern Intel-based server platform if you would like to learn how a coreboot port is integrated into Dasharo and enhanced with its features feel free to ask any questions.

In the blog post, the author explains the effort of porting platform-specific ACPI code and shows the extent of bugfixes required to run operating systems without issues on the AMD Turin server platform, the Gigabyte MZ33-AR1.

Another post about the Gigabyte MZ33-AR1 porting effort progress. This time, we add definitions for PCI Express initialization, and validate BMC KVM VGA and keyboard. Also, improvements to HCL reporting and data dumping on AMD systems have been made.

This is precisely it. Also, maybe some regulatory requirements of cloud providers and organizations like OCP. Commoditizing their complement is probably another obvious goal.

We also have to note that AMD seems to be heading for being a market leader in the server market (some signals are active in OCP Caliptra and OSF). We can see their presence at the upcoming OCP Summit, where they (together with Intel) will push forward the agenda of a generic framework for bootstrapping firmware, which is called openSFI: https://youtu.be/1CE6olXT604

Sovereign Boot Provisioning Wizard is a UEFI application designed to guide end users through the provisioning of UEFI Secure Boot. The objective is to offer a user-controllable mechanism for managing platform trust relationships and establishing UEFI Secure Boot infrastructure, with a primary focus on transparency, informed consent, and usability.

Unlike traditional firmware interfaces, which expose UEFI Secure Boot as a collection of loosely connected toggleable settings and unmanaged certificate stores, this application presents a coherent, wizard-like experience. Its purpose is to make the process of reviewing and enrolling platform keys intuitive for users who are not security experts.

https://docs.dasharo.com/projects/sovereign-boot-wizard/

Having a supply chain that originates in the EU may be of benefit for some customers.

Hi, I'm 3mdeb (the company behind Dasharo) Founder. You can find Dasharo's business model explanations in the following resources:

1. Presentation about Dasharo Revenue Sharing and Dasharo Supporting

https://www.youtube.com/live/ZyctrnJNTPc?si=svfFEO6WXiF3BNqz...

2. Publicly available overview of cooperation models:

https://youtu.be/n2NlymUVYCY?feature=shared&t=115 https://www.youtube.com/live/EN5rBAAOdOk?si=YKrkR28rQE1TyoWe...

https://github.com/Dasharo/presentations/blob/main/archive/d...

Please let me know if anything is missing or if anything is unclear.

You can ask Tim. Those Berbers sitting without any issues on the GitHub for two years already https://github.com/mithro/x11ssh-f-pcb

Possibility of runtime exploration of the system which may help in OpenBMC port.

Thanks for posting, 3mdeb Founder here. To some extent, it is known that Root of Trust provisioning tooling for ARM SoC vendors is problematic. Proprietary, closed source, with documentation available only in Chinese. We did that for many ARM SoCs, and as a result, we published some presentations https://news.ycombinator.com/item?id=43643136

I'm interested in your experience, which AMR SoC has the most Secure boot-friendly ecosystem?

The RISC-V ecosystem is also interesting. Recently, I was looking at Kendryte K230D.

There is continuation of OpenSecurityTraining project https://ost2.fyi/

IUUC Xeno's goal was to create a taxonomy for security topics. If you will take a look here: https://ost2.fyi/System%20Security.html You can find a bigger plan showing the relation between various numbers of courses. Of course, we can only create minimal courses (compared to those taught in universities) about coreboot or UEFI, but in the long run, we should put together one of the most comprehensive firmware training with open and free access for everyone. You can read more about that motivation on other pages of https://ost2.fyi. Security is a broad topic covering various aspects. Please let us know if you have ideas about improving the used taxonomy since it takes enormous effort to put all security topics on the chart and build a map for students that will provide a seamless learning experience.

Thanks for the feedback about the accent. I understand that it can add an unnecessary layer of complexity to content consumption. I will pay special attention to improving it in upcoming classes, but there are some limits to what I can do. In the future, with community and commercial support, we can afford professional domain experts who speak with a good accent.

At this point, we are instead trying to fill the vacuum by providing something, maybe not the most enjoyable, but a basic introduction to the topic to buy some time for domain experts instead of answering basic questions.

I'm pleased that the course I recorded (with massive support from 3mdeb colleagues) and contributed to, OpenSecurityTraining2, made its way here. It is an excellent opportunity to introduce myself and engage with you. I'm Piotr Król, Founder of 3mdeb, a Poland-based open-source firmware vendor, and IBV, the instructor of the OpenSecurityTrainign2 in question. I have developed BIOS and open-source firmware development for 15 years (the last years focusing more on the education and business side of those topics).

This course aims to make the foundational aspects of coreboot more accessible to anyone interested in learning about open-source firmware development. In future classes, we'll dive deep into the nuts and bolts of coreboot, from its architecture to hands-on implementation on hardware. I'd love to invite everyone reading this to check out the course, and whether you're an experienced firmware developer, an open-source enthusiast, or a newcomer curious about coreboot, your perspectives, and questions are all welcome.

Please feel free to ask me anything - about the course, coreboot, my experience in this field, or anything else you'd like to know. I am looking forward to a vibrant discussion!

I'm not a RISC-V expert, primarily relying on open-source firmware community knowledge and the opinion of such figures as Ron Minnich, but AFAIK, most firmware for production RISC-V deployments is closed-source, so we can't say if vendors use OpenSBI implementation or some modified version for their malicious purposes. If I need to be corrected, please point me to products that state how they transparently use SBI. There is evidence of transparent use of SMM in coreboot. SBI is not the only RISC-V TEE. There are also other concepts, like MultiZone [1] and PMP-based Keystone [2], advertised as trusted execution environments

The openness of specification only matters a little here - UEFI specification about management mode is also open. But IBVs screwed us many times [3] by implementing low-quality SMIs that could elevate privileges, and the spec does not guarantee that implementers follow it. Lack of tooling makes compliance difficult - it slowly changes with various startups seeing that as an opportunity (e.g., Binarly, Eclypsium?).

My point is that SMM as TEE is not a unique x86 feature, and other significant architectures have similar mechanisms. OS has a means of figuring out that it was in SMI, so it is not entirely hidden but still has superpowers. In the CNC world SMI latency is measured from OS [4].

Trusted execution environments are hammers and can be used for a good purpose in a transparent way and for malicious purposes. Further typically depends on the trustworthiness of mechanisms implemented and used by vendors, but thus keep the fact that TEEs and peripheral MCUs are everywhere, which may lead to the extended attack surface.

Why do we see those TEEs, peripheral MCUs, everywhere? I like the explanation in this lecture [5]. No architecture can quickly fix that problem.

[1]: https://hex-five.com/multizone-security-tee-riscv/

[2]: http://docs.keystone-enclave.org/en/latest/Getting-Started/H...

[3]: https://research.nccgroup.com/2023/04/11/stepping-insyde-sys...

[4]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?FixingSMIIssues

[5]: https://youtu.be/36myc8wQhLo

Linux is important but FreeBSD is the key to heart of majority of DYI firewall builders. I'm huge fan of your project and looking for opportunities to get hands on experience with it.

I see that support for FreeBSD going in good direction:

https://forum.traverse.com.au/t/freebsd-preview-for-ten64/17...

Are there any performance reports for FreeBSD? Especially VPN/wireguard bandwidth would be interesting.

No, just from not native English speaker. You mention high performance 10GbE hardware without being precise about CPU architecture or vendor/model of the firewall. Apparently high power non-consumer grade hardware, but such hardware lacks PC Engines properties. You also mention accelerators and this is what my comments is about: reality of build firewalls.

My comments is about designs that potentially could meet the requirements, but surprisingly those have different problems. How we know those designs? We consult for firewall vendors doing research. We would be glad to be wrong by being pointed to viable competing solution which can reach score close to PC Engines. Performance is not the only factor for small ISP and security-concious privacy-concerned infrastructure builders.

So it is not that trivial to purposefully build firewall these days that can compete with PC Engines low power consumer/SOHO design.

When we did the research for our network appliance customers, we were very interested in NXP. Have you tried to buy Application Solutions Kit from NXP? We faced the problem of not achieving spec performance using NXP reference boards. After reaching NXP, support informed us that we should buy ASK, which would solve our problems. Unfortunately, it was beyond our research budget.

> I've never seen SMM mode cause down time, nor have I had the non-auditability of the firmware caus me down time.

Hyperscalers (OCP) pushing for coreboot and LinuxBoot have probably different experience. AFAIK they hate SMM especially with SMI handlers coming form unknown source.

Not saying SMI latency is huge problem in industrial applications like CNC.

> due to obtrusive (SMM mode), non-auditable firmware

Let's be honest every architecture has the same problem of parallel "trusted" execution environment, some have even more than one.

- ARM TrustZone

- POWER SBE

- RISC-V SBI

There is no storage limitation on PC Engines, you can get 1TB mSata and put inside and it should work without problems. Also apu2 and other have SATA port inside [1], there is also SD card slot as well as USB.

[1]: https://voidst.one/posts/comprehensive-guide-to-pc-engines-a...

Those are very far from PC Engines:

- no ECC

- no DRTM

- no schematics

- no open-source firmware support

Trustworthiness of those devices is at least questionable.

Today AMD announced [1] Ryzen 5000 with network appliance as target market. I can only imagine how expensive it would be in final design.

[1]: https://www.amd.com/en/newsroom/press-releases/2023-4-20-amd...

Most ARM cases would mean a tremendous amount invested in reverse engineering of binary blobs required to configure network and crypto-accelerators. Also, in most cases, it means no support *BSD like OPNsense and pfSense. That leads to fully proprietary designs, lack of transparency, and limited trustworthiness.

What we were able to realize over the years of writing firmware and researching new solutions for network appliance vendors is that support for accelerators is considered a premium feature and typically is available only behind paywall corporate unobtanium. Consider very respected silicon vendors, such as Marvell [1] or NXP [2].

If you have in mind hardware (no matter if x86, Arm, RISC-V, or POWER) that would be able to mark all checkboxes that PC Engines score [3] with 10G performance, then it would be exciting competition otherwise, we are very far from community expectations, where most BSD users with open-source firmware based hardware choose PC Engines or Protectli [4].

[1]: https://www.spinics.net/lists/linux-crypto/msg53306.html

[2]: https://www.nxp.com/support/support/nxp-engineering-services...

[3]: https://news.ycombinator.com/item?id=35636960

[4]: https://bsd-hardware.info/?view=computers&f=node_coreboot&v=...

Recently we analyzed the Hardkernel offer in light of OpenSecurityTraining2, and it looks pretty good but is more expensive than UP2. For example, the UP Squared Pro 7000 Series [1] is fascinating.

The pros of Hardkernel are open schematics (same as PC Engines), which is crucial if one would like to have open-source firmware like coreboot. Quite good testing documentation, transparency, and community. UP2 does not provide schematics, and their support could be better, which can be proven by reading their forums. There needs to be a sense of transparency and community building for UP2.

Of course, UP2 and Hardkernel products have other drawbacks compared to PC Engines, namely, no D-RTM, fewer NICs, higher TDP, no ECC, etc.

[1]: https://up-shop.org/ups-pro-7000-series.html