You say this isn't a very big step - out of curiosity, how much work would have been involved in getting this release open sourced? And what might be preventing them from releasing the shader ISA?
Specifically curious if this inherently would "let the cat out of the bag" about the specifics of their chip design, for example.
> how much work would have been involved in getting this release open sourced
Close to no actual effort (the headers are autogenerated). However there was probably a lot of work behind the scenes with their legal team/whatever to clear the release.
About the shader ISA, I wish I knew. It's certain that the documentation exists, because they provide it to some developers (I've been told the Maxwell ISA docs are part of the Nintendo Switch SDK), so it's not like they have to write it from scratch.
And AMD provides full docs about it [1] (not sure about Intel), so I don't see how it could provide a significant edge over their competition. Maybe raytracing instructions? But for a motivated reverse engineer this stuff isn't impossible to figure out. I think it's down to company culture and inertia.
I don't know about Arc, but Intel has historically probably been the most open with their GPU docs. AMD's is (while laudable, particularly compared to Nvidia) unfortunately a bit of a autogenned dump without context. Where as Intel's is closer to what I expect out of decent SoC documentation; it'll be about half prose explaining the why(!!), and half the autogenned tables of registers and opcode formats.
AMD's approach seems to be documentation in the style you describe plus employed FOSS developers who get access to internal people, simulators, possibly even source code. Makes it annoying for externals to try to contribute code, but the drivers are good.
It isn't really, and doesn't really do squat for nouveau. Nouveau has been thwarted by the secretful FALCON units, and Nvidia's decision to lock power management and clock management behind high secure mode.
See, in order to make those calls, the command buffer is submitted along with a hash value, plus the firmware itself iirc. Been a while. That firmware is signed with a private key known only to Nvidia, and they don't sign third party firmware.
So nouveau can write all the firmware they want, but they can't actually get access to any functionality gated behind high-secure mode. There are ways*, but unfortunately all of them run afoul of the spirit of DMCA.
> There are ways, but unfortunately all of them run afoul of the spirit of DMCA.
This is not true. There is federal circuit precedent which invalidates the DMCA for exactly those cases
Chamberlain v. Skylink, final court of appeals for the federal circuit opinion, page 39:
"Underlying Chamberlain’s argument on appeal that it has not granted such authorization lies the necessary assumption that Chamberlain is entitled to prohibit legitimate purchasers of its embedded software from “accessing” the software by using it.
Such an entitlement,
however, would go far beyond the idea that the DMCA allows copyright owner to prohibit “fair uses . . . as well as foul.” Reimerdes, 111 F. Supp. 2d at 304.
Chamberlain’s proposed
construction would allow
copyright owners to prohibit exclusively fair uses even in the absence of any feared foul use.
It would therefore allow any copyright owner, through a
combination of contractual terms
and technological measures, to repeal the fair use doctrine with respect to an individual
copyrighted work—or even
selected copies of that copyrighted work. Again, this implication contradicts § 1201(c)(1) directly. Copyright law itself authorizes the public to make certain uses of copyrighted materials.
Consumers who purchase a product containing a copy of embedded software have the inherent legal right to use that copy of the software. What the law authorizes, Chamberlain cannot revoke."
The Americans decided that copywrite wasn't enough so implemented legislation to prevent reverse engineering bypassing IP for "security" reasons.
So they have this interesting little dance they have to do around reverse engineering on whether a software lock constitutes DRM that you are hacking and if that DRM is fit for purpose. Because terrible DRM that is trivial isn't actually DRM.
It gets complicated as a lot of it ends up being ultimately subjective.
In this scenario, is using firmware that you know has not been signed by Nvidia, on a system that you know shouldn't run it unless it has been signed breaking DRM? And is the firmware signing DRM?
DRM applies only to copyrighted works. The functional aspects of a GPU (what actually makes it work and enables you to use it) are not copyrighted, in the same way that a machine's mechanisms aren't (patents might still exist)
Wasn't Tivoisation about DRM preventing you from using a different Linux kernel.
I didn't think that DRM applied only to copywritten works. I don't mind being wrong, but if you could expand on what exactly was wrong and what is the actual situation as I am only saying what I understand to be the situation.
What I meant with DRM was "legallity of breaking it".
If a technological measure that controls access to hardware has no connection to copyright, there's no legal concern about litigation or bad precedent being set.
There was a lot of work done by the Switch hacking community, which uncovered some fatal cryptosystem flaws w.r.t. secretful FALCONs. It is apparently possible to leak the hash against which the secretful falcon compares against in the hardware from the High Security side of things to LS.
It's a fairly in-depth and tricky thing though. Basically you're having to do firmware reverse engineering and basically chaining together ROP gadgets to figure out what the FALCON expects to see to transition into HS mode, and then retrying/cleverly orchestrating things to make it happen.
I haven't had the bandwidth/life situation to really sit down and cobble together the requisite set of skills to make inroads on proving my hunch that one could use some of the methods described to front-run the HS signed firmware check with the right gadget. Heck, last note I have, I was still trying to figure out how to setup linux kernel code such that I could get a reasonably ergonomic "attempt load firmware blob, gracefully fail to try again" to get a decent test rig going for the experiment to at least make the requisite facechecking of my own ignorance required endurable until I could get a PoC sorted. If I could manage to do it, I guess I'd be in a decent position to hit up EFF and see if I can be a decent legal test case to see if I could squeak through in terms of the exception for reverse engineering something to restore it to it's previous functioning. (Older cards not having secretful shenanigans to deal with) or something. The legal nastiness is actually part of what has kept me from making much in the way of progress even though I really, really want to do it.
If my reading of supporting documentation is right though, it's technically possible, you just have to be really patient and not give up.
Also note, this would almost certainly attract legal attention, because it is HS mode that secures a bunch of the HDMI related DRM functions as well. As demonstrated in that write up, you can bubble out the hashes of keys burnt in in the manufacturing process. Just because you don't have DMCA to worry about, doesn't mean it won't rear it's head elsewhere. There's a lotta money at stake.
I don't care half so much about that the HDMI though as the power management and reclocking shenanigans; there was absolutely 0 reason to lock that behind HS mode other than Nvidia wanting to create vendor lock-in, and prevent users/non-Nvidia developers from being able to write their own firmware.
If you beat me to the experiment, go with the knowledge you're doing $deity's work, and good hunting.
Specifically curious if this inherently would "let the cat out of the bag" about the specifics of their chip design, for example.