Who Is Thinking About Open Source Firmware?

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?

NVIDIA Releases Drivers With Openness Flavor

This year, we’ve already seen sizeable leaks of NVIDIA source code, and a release of open-source drivers for NVIDIA Tegra. It seems NVIDIA decided to amp it up, and just released open-source GPU kernel modules for Linux. The GitHub link named open-gpu-kernel-modules has people rejoicing, and we are already testing the code out, making memes and speculating about the future. This driver is currently claimed to be experimental, only “production-ready” for datacenter cards – but you can already try it out!

The Driver’s Present State

Of course, there’s nuance. This is new code, and unrelated to the well-known proprietary driver. It will only work on cards starting from RTX 2000 and Quadro RTX series (aka Turing and onward). The good news is that performance is comparable to the closed-source driver, even at this point! A peculiarity of this project – a good portion of features that AMD and Intel drivers implement in Linux kernel are, instead, provided by a binary blob from inside the GPU. This blob runs on the GSP, which is a RISC-V core that’s only available on Turing GPUs and younger – hence the series limitation. Now, every GPU loads a piece of firmware, but this one’s hefty!

Barring that, this driver already provides more coherent integration into the Linux kernel, with massive benefits that will only increase going forward. Not everything’s open yet – NVIDIA’s userspace libraries and OpenGL, Vulkan, OpenCL and CUDA drivers remain closed, for now. Same goes for the old NVIDIA proprietary driver that, I’d guess, would be left to rot – fitting, as “leaving to rot” is what that driver has previously done to generations of old but perfectly usable cards. Continue reading “NVIDIA Releases Drivers With Openness Flavor” →

Hackaday Podcast 168: Math Flattens Spheres, FPGAs Emulate Arcades, And We Can’t Shake Polaroid Pictures

Join Hackaday Editor-in-Chief Elliot Williams and Staff Writer Dan Maloney as they review the top hacks for the week. It was a real retro-fest this time, with a C64 built from (mostly) new parts, an Altoids Altair, and learning FPGAs via classic video games. We also looked at LCD sniffing to capture data from old devices, reimagined the resistor color code, revisited the magic of Polaroid instant cameras, and took a trip down television’s memory lane. But it wasn’t all old stuff — there’s flat-packing a sphere with math, spraying a fine finish on 3D printed parts, a DRM-free label printer, and a look at what’s inside that smartphone in your pocket — including some really weird optics.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments below!

Direct Download link.

Continue reading “Hackaday Podcast 168: Math Flattens Spheres, FPGAs Emulate Arcades, And We Can’t Shake Polaroid Pictures” →

This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned

F5’s BIG-IP platform has a Remote Code Execution (RCE) vulnerability: CVE-2022-1388. This one is interesting, because a Proof of Concept (PoC) was quickly reverse engineered from the patch and released on Twitter, among other places.

HORIZON3.ai researcher [James Horseman] wrote an explainer that sums up the issue nicely. User authentication is handled by multiple layers, one being a Pluggable Authentication Modules (PAM) module, and the other internally in a Java class. In practice this means that if the PAM module sees an X-F5-Auth-Token, it passes the request on to the Java code, which then validates the token to confirm it as authentic. If a request arrives at the Java service without this header, and instead the X-Forwarded-Host header is set to localhost, the request is accepted without authentication. The F5 authentication scheme isn’t naive, and a request without the X-F5-Auth-Token header gets checked by PAM, and dropped if the authentication doesn’t check out.

So where is the wiggle room that allows for a bypass? Yet another HTTP header, the Connection header. Normally this one only comes in two varieties, Connection: close and Connection: keep-alive. Really, this header is a hint describing the connection between the client and the edge proxy, and the contents of the Connection header is the list of other headers to be removed by a proxy. It’s essentially the list of headers that only apply to the connection over the internet. Continue reading “This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned” →

Can You Help NASA Build A Mars Sim In VR?

No matter your project or field of endeavor, simulation is a useful tool for finding out what you don’t know. In many cases, problems or issues aren’t obvious until you try and do something. Where doing that thing is expensive or difficult, a simulation can be a low-stakes way to find out some problems without huge costs or undue risks.

Going to Mars is about as difficult and expensive as it gets. Thus, it’s unsurprising that NASA relies on simulations in planning its missions to the Red Planet. Now, the space agency is working to create a Mars sim in VR for training and assessment purposes. The best part is that you can help!

Continue reading “Can You Help NASA Build A Mars Sim In VR?” →

With Rocket Lab’s Daring Midair Catch, Reusable Rockets Go Mainstream

We’ve all marveled at the videos of SpaceX rockets returning to their point of origin and landing on their spindly deployable legs, looking for all the world like something pulled from a 1950s science fiction film.  On countless occasions founder Elon Musk and president Gwynne Shotwell have extolled the virtues of reusable rockets, such as lower operating cost and the higher reliability that comes with each booster having a flight heritage. At this point, even NASA feels confident enough to fly their missions and astronauts on reused SpaceX hardware.

Even so, SpaceX’s reusability program has remained an outlier, as all other launch providers have stayed the course and continue to offer only expendable booster rockets. Competitors such as United Launch Alliance and Blue Origin have teased varying degrees of reusability for their future vehicles, but to date have nothing to show for it beyond some flashy computer-generated imagery. All the while SpaceX continues to streamline their process, reducing turnaround time and refurbishment costs with each successful reuse of a Falcon 9 booster.

But that changed earlier this month, when a helicopter successfully caught one of Rocket Lab’s Electron boosters in midair as it fell back down to Earth under a parachute. While calling the two companies outright competitors might be a stretch given the relative sizes and capabilities of their boosters, SpaceX finally has a sparing partner when it comes to the science of reusability. The Falcon 9 has already smashed the Space Shuttle’s record turnaround time, but perhaps Rocket Lab will be the first to achieve Elon Musk’s stated goal of re-flying a rocket within 24 hours of its recovery.

Continue reading “With Rocket Lab’s Daring Midair Catch, Reusable Rockets Go Mainstream” →

Robot arm in Blender

Animate Your Robot In Blender

You’ve built a robot crammed full of servos and now you settle down for the fun part, programming your new dancing animatronic bear! The pain in your life is just beginning. Imagine that you decide the dancing bear should raise it’s arm. If you simply set a servo position, the motor will slew into place as fast as it can. What you need is an animation, and preferably with smooth acceleration.

You could work through all the math yourself. After half an hour of fiddling with the numbers, the bear is gracefully raising it’s arm like a one armed zombie. And then you realize that the bear has 34 more servos.

render of industrial robot type arm with pedestal, base, upperarm and lowerarm and IK ball

Fortunately for everybody who’s done the above, there’s Blender. It’s all about creating smooth motion for animations and computer graphics. Making robot motion with Blender is, if not easy, at least tolerable. We made a sample project, a 3-axis robot arm to illustrate. It has a non-moving pedestal, rotating base, upper arm, and lower arm. We’ll be animating it first in Blender and then translating the file over to something we can use to drive the servos with a little script.

Now, Blender is notorious for a difficult user interface. The good news is that, with revision 2.9, it moved to a much more normal interface. It still definitely is a large program, with 23 different editors and literally thousands of controls, but we’ll only be using a small subset to make our robot move. We won’t teach you Blender here, because there are thousands of great Blender tutorials online.  You want to focus on animation, and the Humane Rigging series is particularly recommended.

Continue reading “Animate Your Robot In Blender” →