Turing

WHAT! New NVIDIA hacks are dropping?!

This came across my feed, as a newish drop from another hobby reverse engineer out there in the world. Then I saw more information about it in a drop from Tom's Hardware.

The claim seemed too good to be true, a 10x memory increase with just software induced hardware changes from eFuses?! So I got to reading and quickly made sense of what was going on, the HBM2 & HBM memory modules from this gen were just binned different based on addressable memory reliability and economics seemingly.

Now I don't have any HBM or stacked die GPUs to play with. But it made me realize something; in this world of AI delegation and the ever increasing breakdown of interfaces between hardware security and software security, surely I can use other researchers findings to check if there's similarly unlockable or differently binned features on other GPUs that were binned from higher spec dies?

And of course once I went down that rabbit hole I found there is absolutely a burgeoning section of people collaborating to do exactly this! Unlock prosumer features on older GPUs, increase performance and longevity, upgrade what you have. The exact sort of thing that appeals to my delicate sensibilities. That's the story of how I found NV UEFI Unlocker.

Now, they make some big claims about CUDA performance and FP16 performance unlocking. That's great and all, I even have a fully supported card and one not supported card. Not supported are big words, and it's certainly enough to get me going. This project is targeting AI FP16 performance and that's ok, but what about if similar findings are applicable outside of high performance computing, on devices that will never be more than what they are, simple low range consumer devices.

Now let's talk more about the differences between these two projects, because they're related, but they're attacking two fundamentally different problems.

The first project, Kate's GA100 exploit, is attacking hardware-level restrictions. NVIDIA takes a GPU die, tests and bins it, then permanently disables various capabilities using electronic fuses (eFuses). Through some absolutely brilliant voltage fault injection work, Kate discovered a way to manipulate the fuse controller and effectively reverse restrictions by blowing additional fuses. Yes, you read that correctly. Blowing MORE fuses to UNLOCK hardware.

That's an absolutely fascinating failure of hardware security design, and the results are spectacular. We're talking about recovering physically present HBM memory, additional streaming multiprocessors (SMs), and other disabled hardware capabilities.

The second project, nv-uefi-unlocker, is doing something quite different. Rather than recovering disabled physical hardware, it's exploiting the GPU's early initialization process to lift certain artificially imposed computational throughput restrictions. It executes before the operating system's GPU driver initializes, modifies protected hardware configuration, and hands control back to the operating system.

No soldering. No permanently blown fuses. No VBIOS flashing. Power-cycle the machine, and the changes disappear.

Neither of these magically add CUDA cores or VRAM, but on supported GPUs it can substantially improve certain FP16 and Tensor Core workloads without any change to the underlying hardware.

---

Now here's where my brain started doing that dangerous thing where it connects two completely different bleeding edge research projects and invents a third one.

To just help everyone keep their old gaming hardware alive longer would probably be better for the broader consumer market but it has less economic incentive than min-maxxing FP16 and AI inference performance.

What if we take what we're learning about the hardware restrictions from the first project, combine it with the early-boot firmware and register access techniques from the second, and start investigating whether there are other disabled features that can be recovered?

As it turns out, NVIDIA's Turing generation is particularly interesting for exactly this reason. Several products share the same physical GPU dies, but ship with different numbers of enabled streaming multiprocessors. Sometimes that's because hardware failed manufacturing tests. Sometimes it's simply product segmentation.

Enter my sacrificial lamb: a PNY GTX 1650 with a TU117-300-A1 GPU.

This particular chip has 896 enabled CUDA cores, but a fully enabled TU117 has 1,024. That's two entire streaming multiprocessors, or one TPC, disabled on the chip. A theoretical 14.3% increase in shader resources if that hardware is functional and we can figure out how to enable it.

Now, to be clear, nobody has demonstrated a successful TU117 shader-core unlock using these methods, and the existing UEFI unlocker's principal Tensor Core performance improvement doesn't apply to this card because the GTX 1650 doesn't have Tensor Cores.

But that leaves us with an interesting question: What exactly is disabling that missing TPC, and can we do anything about it?

And THAT sounds like a reverse-engineering project fit for a few weekends.

The board also has an ISSI IS25WP080 SPI flash containing its VBIOS, which opens up another entertaining possibility. I'm considering removing it, dumping the original firmware, and replacing it with an external flash emulator. That would let me experiment with boot firmware without having to repeatedly desolder and reprogram the chip. In fact I have already purchased the hardware to do this. (As though the universe hasn't already practically begged me to stop dumping random flash chips, but it's a habit, a bad one. And it can't be satisfied.)

I'll also be setting up a dedicated Arch Linux environment to interrogate the GPU's PCIe registers, inspect its hardware configuration, and investigate what happens during initialization.

Maybe we'll find a software-controlled restriction. Maybe we'll find a permanent hardware fuse. Maybe we'll find that NVIDIA disabled that particular piece of silicon on my device because it was genuinely defective.

Maybe I'll just make a perfectly functional graphics card from yesteryear into an over-engineered paperweight.

All of those outcomes sound educational to me. 🤣

The goal isn't necessarily to turn a $50 GPU into a $75 GPU. It's to better understand where the boundaries between silicon, firmware, and software actually exist, and whether those boundaries can be moved.

And if I can document something useful along the way, maybe the next person poking around inside one of these old cards won't have to start from scratch. What if there's a universe where this helps someone save time or money. Let's find out...

So that's the next rabbit hole. Let's see how much of a TU117 NVIDIA will let me have before it stops cooperating.