Yesterday, we ran a post on NVIDIA’s announcement of open-source drivers for some of its most recent video cards. And Hackaday being huge proponents of open-source software and hardware, you’d think we’d be pouring the champagne. But it’s trickier than that.
Part of the reason that they are able to publish a completely new, open-source driver is that the secrets that they’d like to keep have moved into the firmware. So is the system as a whole more or less open? Yeah, maybe both.
With a more open interface between the hardware and the operating system, the jobs of people porting the drivers to different architectures are going to be easier. Bugs that are in what is now the driver layer should get found and fixed faster. All of the usual open-source arguments apply. But at the same time, the system as a whole isn’t all that much more transparent. The irony about the new NVIDIA drivers is that we’ve been pushing them to be more open for decades, and they’ve responded by pushing their secrets off into firmware.
Secrets that move from software to firmware are still secrets, and even those among us who are the most staunch proponents of open source have closed hardware and firmware paths in our computers. Take the Intel Management Engine, a small computer inside your computer that’s running all the time — even while the computer is “off”. You’d like to audit the code for that? Sorry. And it’s not like it hasn’t had its fair share of security relevant bugs.
And the rabbit hole goes deeper, of course. No modern X86 chips actually run the X86 machine language instructions — instead they have a microcode interpreter that reads the machine language and interprets it to what the chip really speaks. This is tremendously handy because it means that chip vendors can work around silicon bugs by simple pushing out a firmware update. But this also means that your CPU is running a secret firmware layer at core. This layer is of course not without bugs, some of which can have security relevant implications.
This goes double for your smartphone, which is chock-full of multiple processors that work more or less together to get the job done. So while Android users live in a more open environment than their iOS brethren, when you start to look down at the firmware layer, everything is the same. The top layer of the OS is open, but it’s swimming on top of an ocean of binary blobs.
How relevant any of this is to you might depend on what you intend to do with the device. If you’re into open source because you like to hack on software, having open drivers is a fantastic resource. If you’re looking toward openness for the security guarantees it offers, well, you’re out of luck because you still have to trust the firmware blindly. And if you’re into open source because the bugs tend to be found quicker, it’s a mix — while the top level drivers are made more inspectable, other parts of the code are pushed deeper into obscurity. Maybe it’s time to start paying attention to open source firmware?
My guess is : No Chance.
As they need to disclose the detailed operation of pipelines and cores.
Closed source firmware may be a requirement for commercial rivalry & marketing flexibility. (think of dies being equal, yet different models with different features) Also firmware on PC hardware behaves more as an extension & interface to the hardware than anything else. Who’s better to implement that than the guys who came up with the silicon itself.
Firmware is way too generic a term. It gets used for software (in microcontrollers), gateware (in FPGAs) and lookup tables (in microcode).
Open sourcing the software stuff makes sense. I’m not sure about the gateware or LUT versions: I doubt it would help with bugs because you need the entire rest of the hardware.
For FPGA you may also need the development tools used, Intel (Altera) have started to remove all Quartus (analysis and synthesis tool) that are more than 5 years from their download website.
I noticed this change while trying to write gateware for one of the older fully opensource LimeSDR SDR boards that used Intel (Altera) chips. The latest LimeSDR Mini 2.0 will use Lattice FPGA chips (ECP5) which has an extensive set of open source tools.
Oh, for FPGAs, you need more than that – you might even need the random seed used for the build itself, because depending on the tool it may or may not be deterministic. Repeated builds aren’t guaranteed to be identical – they’re just shooting to meet the timing constraints provided.
Yeah, but. I’d be stoked to have the VHDL/Verilog source, at least for the parts that aren’t IP. And the interfaces of the IP blocks, and you’ve got a chance…
But that wouldn’t be able to tell you how the device works. You’d actually be better off asking the vendor to provide a functional simulation if you wanted to understand how to interact with it and any issues it had.
Yes, firmware is a bit of a wide term at times.
Since it can be anything from basic hardware configuration all the way to a full on software stack with a (real time) OS, web interface and everything.
But effectively speaking, it is more or less just a hardware specific stack of software.
Though, given how much software there is in modern GPUs, CPUs and other larger system components really makes one wonder what all that software is for and how much is actually needed.
Mostly, people want the boards to work, like in other operating systems. To show images, run 3D acceleration, etc.
The crowd that “wants to know how it is done” can be grouped separately, but at least this allows ( hopefully )for the cards to run correctly in open-source OSs.
And people who care about security or privacy would also fit into that second category you created. “run correctly” does not exclude riddles with security holes. Graphic security has a very large attack surface. e.g. hardware DMA attacks on a CPU using a GPU – it is not like a kernel running on a CPU can block the GPU with access to the PCIe bus from transferring data between blocks of memory. That was a design flaw because the assumption was that GPU’s would not be used to compromise the security of a computer (or any other PCIe card for that matter).
“it is not like a kernel running on a CPU can block the GPU with access to the PCIe bus from transferring data between blocks of memory. ”
Yeah, you might want to google “IOMMU.”
Now it can, but that was not always the case.
They are open-sourcing the whole driver, just the part the is in the Kernel. Userland software will still be closed-source (see https://arstechnica.com/gadgets/2022/05/nvidia-takes-first-step-toward-open-source-linux-gpu-drivers/ ). This a good start for security and stability, but won’t probably give much insights about the internals of the GPU behavior.
yeah sometimes i care about arbitrarily deep transparency. for example, i wanted to get into FPGAs 20+ years ago and i hated how closed all of it was, i wasn’t willing to use them unless i had an open source ‘compiler’ for them. but these days for most of my needs, mostly i just care that it works. so firmware with few bugs and a published interface is good enough for me. really always was, most of the time.
what i really hated was how hard it used to be to get documentation, even for nominally open interfaces. like, to use IPX networking under DOS 25 years ago…i didn’t want the source to the driver, i just wanted to be able to use its API. i could get little clues here and there, spent a long time with ralf brown’s list, but i never really understood the interface. i don’t run into that too often anymore.
in my present day life, my daily laptop has a wifi bug that requires resetting the driver (suspend the laptop) about once a month. takes about 5 seconds but stops me in my tracks until i do it. the open source driver is, like a lot of open source drivers, little more than a message passing interface to the firmware driver. i haven’t bothered doing a deep dive on it (especially because the problem is so sporadic), but i have the feeling that if i do, the best i’ll be able to do is come up with a more-elegant work-around for some bug in the firmware. it’s discouraging to have that suspicion before you even start, but the fact of the matter is i have dozens of these firmware blobs in my life and this is the only one that bothers me on a regular basis.
don’t get me started on raspberry pi though :)
Luckily, fully open-source FPGA toolchains have come a long ways recently, if mostly for lattice boards (though I’m messing around with project Apicula and nextPNR for gowin chips). This also depends on continued goodwill from lattice, as it would be pretty easy to encrypt a bitstream if you really wanted to, and their documentation seems to be purposefully well-suited to reverse engineering.
One big reason “Firmware” and “Drivers” remain closed is greedy Trial Lawyers. The moment you open something like a video driver up, Patent Trolls will pick through it like a swarm of dung flies. Then the law suits start dropping. It’s just not worth taking a chance, especially in the U.S. where the U.S. Patent and Trade Office (USPTO) has become totally corrupt and politicized.
“Greedy trial lawyers” have clients. Those are the ones one should be mad at.
When you think about it, a lawyer is a biological expert knowledge system which you instruct to solve a problem in the legal sphere, and it translates to and from legalese to English to let you know how it’s going and developments in the progress towards a solution. You set them off in a kind of battlebots arena known as a courtroom and if your bot wins it’s all good, if it doesn’t it costs you a lot and it’s back to the drawing board.
Continuing the analogy: law can be thought of as the world’s most obscure and buggy programming language. It is incredibly difficult to write new low-level routines that do what you intend them to do. Hence the tendency for lawyers to copy language verbatim from previous tested documents, even if that language is archaic or poorly written — or even buggy, as long as they know what the bugs are and can build the system to prevent those failure modes from ever arising when their higher-level product is running
They aren’t (usually) deliberately trying to be obscure — they just know how much risk there is if creating new bugs if they try to clean up the code, and are terrified of having to take responsibility for that.
As long as the firmware actually means firmware, meaning none of it is executed by the host operating system controlled CPU, I’m totally find with firmware blobs even though I would want everything open sourced.
Combined with IOMMU the firmware can be assumed to be part of the hardware and the only reason you need firmware blob in the first place is that GPU manufacturers skipped adding the required flash space to store the firmware inside the GPU.
Firmware that needs to be pushed to GPU during the initialization only can be considered as a really complex handshake to start the GPU hardware.
If “firmware” actually means some kind of host CPU compatible black box executable code that’s run in ring 0, it’s not acceptable solution in long run.
Welcome open-hardware !
Who’s been thinking about OS firmware? Bryan Cantrill and friends. I don’t have any firsthand experience with their products (not released yet?), but check out
https://oxide.computer/blog/another-vulnerability-in-the-lpc55s69-rom
https://github.com/oxidecomputer
Also check out the OpenSource Firmware conference coming up: https://www.osfc.io/
Cool!