Nouveau: NVIDIA's New Hardware Is "VERY Open-Source Unfriendly"

[moilami]

That someone was Richard M. Stallman, and I never understood why either. He is basically saying that software becomes hardware when it is unchangeable by the user, which is IMHO a very weird view, especially when one sees his views about tivoization, which is basically software tied to the hardware.

What is so hard to understand in that? When you can't change the software, it would be more or less in vain to study the software because you could not improve the software and share the improved software, much less change the software alltogether. Hence the software you can't change is in practise hardware.

[bridgman]

What is so hard to understand in that? When you can't change the software, it would be more or less in vain to study the software because you could not improve the software and share the improved software, much less change the software alltogether. Hence the software you can't change is in practise hardware.

So why, then, if you take that microcode image and put it in flash ROM and load it with BIOS code it remains "hardware" (despite the fact you can change it), but if you take the same microcode image and put it in a file it becomes "software" ?

[moilami]

What is so hard to understand in that? When you can't change the software, it would be more or less in vain to study the software because you could not improve the software and share the improved software, much less change the software alltogether. Hence the software you can't change is in practise hardware.

Or better said, software none can change is in practise hardware.

[SystemCrasher]

Double standards in open source? Oh, snap!

Yes, that represents one of the significant concerns. In the case of Intel CPU microcode, for example, this can be stored and loaded from the BIOS at power-on, all without requiring distribution with the operating system. This is a huge win from a marketing perspective - Debian, Trisquel, Guix, etc. can advertise a distribution that is 100% free software

....and that's where it turns into "marketing bullshit" and double standards.

Firmware in flash IC is not anyhow better or worse than firmware in RAM - it stays (often) closed source binary which you can't easily change (due to lack of source). Good example of right approach can be seen at Qualcomm-Atheros, who opened source of firmware for their USB ICs supported by ath9k_htc.

Actually, firmware in, say, flash ROM of your HDD would have no trouble to return wrong data when you read some sector. Possibly hijacking system and gaining control over it by putting own code from hidden area you'll never see. Yet, FSF zealots are dumbass enough to ignore this issue.

But each ignorance and double standards come with price. Have you ever heard of Equation group? These ones created some fancy thing for their malware: HDD infection module. It able to re-flash some HDDs with patched firmware, which would eventually try to hijack OS. Giving it unimaginable persistence. It is no matter if you format HDD or reinstall OS, there is no escape. And the fact you can't see that damn firmware would not anyhow save your butt from hostile actions firmware takes. Actually, you never know what firmware in flash would do. And in fact, it is easier to check RAM-loadable firmware than flash-based firmware.

It is as simple as that: when you upload firmware to RAM, you can check if it has been changed, etc. If firmware resides in flash... most of times you can't even read it reliably, because it would be firmware who does all communications, so if it wants to lie to you, there is no prob to return false firmware dump, etc.

I think it is really good time for all these FSF mammoth nuts to stop being retarded and recognize that nearly all peripheral runs some service processors, they run some code and this code haves enough room for doing harmful actions. And it is not a big deal if this code hidden in flash or uploaded at powerup to RAM. In fact, code hidden in flash is even worse as you can't even see it but it exists and can inflict damage.

[duby229]

So why, then, if you take that microcode image and put it in flash ROM and load it with BIOS code it remains "hardware" (despite the fact you can change it), but if you take the same microcode image and put it in a file it becomes "software" ?

You know the odd thing is that a similar question can be posed from a different angle. Why is it firmware if its executed on the CPU's processor, but microcode if its executed on an on-die processor? Why does it matter where it's executed? If it's code, then it's code right? When has code ever been hardware?

[bridgman]

You know the odd thing is that a similar question can be posed from a different angle. Why is it firmware if its executed on the CPU's processor, but microcode if its executed on an on-die processor? Why does it matter where it's executed? If it's code, then it's code right? When has code ever been hardware?

Yep, welcome to the slippery slope. The hardware is designed as source code too (VHDL or Verilog, I forget) that gets compiled down through a series of tools and ends up as masks. You can say "oh that's different from the microcode" but if I take microcode source and build it into an on-chip ROM it goes through pretty much the same toolchain as the logic circuits, goes into the same masks, and gets fabricated at the same time as the random logic.

There was a time when you could look at a piece of hardware and *sometimes* be satisfied that it could not affect the operation of the system and CPU (eg the lines required to do bus mastering writes were not hooked up) but those days are long gone. CPUs, GPUs, disk & network controllers, pretty much every peripheral does scatter/gather accesses to system memory.

I fully understand the desire for microcode source (and hardware design details), I just don't get the distinction between microcode-in-ROM, microcode-in-flash and microcode-in-a-file, other than the (misplaced IMO) belief that flash can't be updated without your knowledge while files on a drive can. Maybe I'm missing something, but it seems easier to control updates to microcode in a file than to microcode in a flash.

[moilami]

The microcode is still necessary because it is a common and convenient way to design hardware. Nearly all of the CPU and GPU hardware available today uses non-free microcode -- the only thing different about AMD is that we load relatively more of the microcode into RAM on the chip at power-up rather than burning it into permanent ROM or having BIOS load it from flash ROM.

Microcode is part of the hardware design, and freeing it is not a priority for the same reason that freeing the rest of the hardware design is not a priority.

IMO the root problem here is that a reasonable concern (the ability to change HW microcode without user knowledge or approval) has led to an unreasonable conclusion (soft-loaded HW microcode is evil and must be removed or freed). Having the driver soft-load microcode from files is no different from having BIOS soft-load microcode from the flash ROM image, but the former is "bad" while the latter is considered OK.

As I understand it, there are a few core arguments that come up:

1. Evil companies might sneak in a microcode update which removes or breaks existing functionality without your knowledge. Given that we are talking about an open source OS and open source kernel driver, this should be handled by controlling updates to the microcode files (eg maintaining checksums for each ucode file and warning user if they change).

2. Evil companies might update the microcode to add new features you like, "forcing" you to accept the update, while at the same time removing or breaking functionality we need. In this case I think the answer is to not take the update if it has undesirable side-effects -- hardware with burned-in microcode can't be updated at all, so there is no disadvantage relative to devices with hardwired microcode.

(by the way I'm not a big fan of disabling CPU microcode updates just because they *might* contain something bad -- new microcode files get a fair amount of test coverage before being included in a distro release so risk of breakage seems really low)

3. Evil companies (or third parties) might include back-doors in the microcode which steal your information. OK, but this is an equal concern whether the microcode is burned into HW or soft-loaded at startup. The key thing here IMO is controlling & validating the updates, not prohibiting them or prohibiting soft-loaded microcode. Saying that soft-loaded microcode must be free while recommending HW with large amounts of hard-wired microcode (eg Loongson CPUs) seems to be missing the point IMO.

As a fresh Shadowrun fan and content with this world with the similarities to the Shadowrun world I greatly applaud this posting and certainly offer you a beer in Michael's way, if I ever get a chance to do that

[duby229]

Yep, welcome to the slippery slope. The hardware is designed as source code too (VHDL or Verilog, I forget) that gets compiled down through a series of tools and ends up as masks. You can say "oh that's different from the microcode" but if I take microcode source and build it into an on-chip ROM it goes through pretty much the same toolchain as the logic circuits, goes into the same masks, and gets fabricated at the same time as the random logic.

There was a time when you could look at a piece of hardware and *sometimes* be satisfied that it could not affect the operation of the system and CPU (eg the lines required to do bus mastering writes were not hooked up) but those days are long gone. CPUs, GPUs, disk & network controllers, pretty much every peripheral does scatter/gather accesses to system memory.

I fully understand the desire for microcode source (and hardware design details), I just don't get the distinction between microcode-in-ROM, microcode-in-flash and microcode-in-a-file, other than the (misplaced IMO) belief that flash can't be updated without your knowledge while files on a drive can. Maybe I'm missing something, but it seems easier to control updates to microcode in a file than to microcode in a flash.

Thanks you, of course you're absolutely right. The real truth of the matter is IMO, we wouldn't have the OSS drivers we have today if AMD hadn't implemented them with the proprietary microcode. I would love to see an open source implementation of the microcodes themselves. If a drop in replacement could be coded for the microcodes I'd truly be a happy man, but for now I fully understand why things happened the way they did. And I generally agree with the course of actions that are leading into the future.

I just hope somewhere along the way someone shocks the community by releasing a working system for microcode replacement.

[boltronics]

We discussed this with board vendors and FSF, but neither of us were able to convince a board vendor to spend the extra $$ for larger flash ROM and added support burden (see next point).

That's terrific. It's great to see AMD making these attempts, even if they have not yet been successful.

The problem here IMO is that somewhere along the way someone decided that microcode in a file was "non-free software" but the same microcode in a flash ROM or burned into the chip was "hardware". HW microcode doesn't become "software" just by being copied into a file.

From my recollection of events, this mostly comes back to discussions around the Linux kernel being referred to as "free software". I remember there was a big deal about it on Slashdot some years back (where many were shocked to learn that the Linux kernel wasn't completely free), and the response from a few developers was to de-blob the kernel. This old article listed some of the concerns at the time: http://www.linux-magazine.com/Online...-libre-Project

So then at around 2009, a few things happened. The Linux Libre project (http://www.fsfla.org/ikiwiki/selibre/linux-libre/) sprang to life to continue the de-blobbing work and the FSF's Licensing and Compliance Lab created a "Free GNU/Linux distributions" page that gave distributions that met certain criteria official endorsement: https://web.archive.org/web/20090419...e-distros.html

Ever since then, Trisquel and every other distribution on the page that is considered free software by the FSF must be running a de-blobbed kernel such as Linux Libre. See the kernel column of the Trisquel release pages for an example of this: https://en.wikipedia.org/wiki/Trisquel#Release_history. Even the Debian project decided that releasing non-free microcode was against their free software guidelines and jumped on board.

The thing is, this all happened around 6 years ago, and has been a problem ever since. AMD's microcode license is still absolutely horrible, for no apparent reason. I can't say I blame the developers for the Linux de-blobbing work since as the Linux Magazine article points out:

"[O]nce the gates were open, other blobs with various misfeatures started to flow into the Linux sources: some had licenses that were clearly proprietary, explicitly stating they were generated out of secret source code, forbidding reverse engineering and imposing several other GPL-incompatible restrictions. Others have free software licenses, [and are] GPL-compatible except for the lack of source code, but they?re no longer tiny: some are entire operating systems that run on peripherals, weighing more than early versions of Linux itself." -Alexandre Oliva

So once they were in that situation, how could they draw the line at "this firmware or this microcode has no source code and is too big", "this license is too restrictive", etc? There are no guidelines specifically for ethical firmware and microcode, so it ultimately was governed by existing free software guidelines by default.

I look forward to the day that I can just install my favourite GNU/Linux distro and have it just work out of the box, and I can proudly recommend AMD hardware to all without reservation. Even if it's hard to do something about the situation *right now*, I hope AMD continues to keep this issue on its radar so it can at the very least provide a better end-user experience across all distributions in the near future.

[nanonyme]

Pick your poison... great drivers with open-source unfriendly hardware or the exact opposite with AMD.

AMD graphics drivers are barely acceptable and still are subpar for OpenGL, even on Windows, since Fglrx and AMD Windows Catalyst drivers are about the same for OpenGL performance.

Also how many Nvidia driver releases has there been since even a single stable release from AMD? I'm still waiting for an official 15.3 driver.

Just a hunch but I suspect AMD will wait for Windows 10 on updates unless critical fixes are implemented