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.
Sorry, I just noticed this comment. I know you probably won't see this, but that's not what I meant!
What I wanted to write and the reason why I noticed the accent was not because it was bad, but because I'm also Polish, so I am especially sensitive to Polish accents (and I hate hearing myself speak foreign languages, so there's that)! The same way, for example, Swedish speakers hate hearing their own countrymen speak Swedish! I didn't mean for it to be taken so seriously!
Also, IMO, videos which are voiced by their creators sound better, more genuine. I'd honestly prefer it if you were to practice your pronounciacion just a bit more and the videos would be perfect!
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!
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.
No, we haven't bought any ASKs. We have worked with them on a DPDK project and they were quite helpful when it came to debugging difficult bugs with it.
Improving the routing performance in Linux is near the top of my TODO list, however. XDP is one candidate (see https://forum.traverse.com.au/t/vyos-build-my-repo/181/5 for some results) and using the LS1088's AIOP is another possibility.
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:
dsl (Dmitry) is the main developer behind the DPAA2 drivers for FreeBSD and he's done a fantastic effort so far. Myself and Bjoern (bz) have also written bits of it.
The performance has improved compared to how it was a year ago (e.g struggling to get 400mbps throughput) but there are some severe issues in -CURRENT :( I believe dsl is trying to get them fixed by 14.0-RELEASE.
> 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.
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.
There's little RISC-V could do to prevent bad SMIs.
It already did well enough by standardizing SBI and by providing a high-quality open implementation of it.
This minimizes (or even removes) incentives to provide a proprietary solution.
Some vendors will of course do whatever they want, instead of just using opensbi.
But they'll be opting out of being compliant with the platform specs, and of benefiting from the support for SBI present in operating systems and embedded toolchains. Such an implementation would just make themselves and everybody else miserable.
In an ideal world, the market will avoid non-compliant SoCs. In practice, there will be some of these to point at as examples of how not to operate.
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.
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].
Did I just get a message from ChatGPT? Because this comment doesn't quite make sense. I said nothing about ARM, and those links don't lead to quite where I'd expect.
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.
