[Nouveau] How to reverse engineer a PCI-Express driver under Linux ?

[Ilia Mirkin]

On Wed, Mar 3, 2021 at 5:30 AM Karol Herbst <kherbst at redhat.com> wrote:
>
>
>
> On Wed, Mar 3, 2021 at 11:07 AM Tomek LECOCQ <tomek.lecocq at hotmail.fr> wrote:
>>
>> Hello,
>>
>> I’ve already asked this on the Kernel Newbies mail list, but as developing nouveau seems to be kind of similar to what I want to achieve, I thought it would be a good idea to ask it here as well.
>>
>> I have a PCI-Express video capture card that has a proprietary driver for Linux.
>> I have some experience with programming in C, and so I would like to start a hobby project to develop a free/libre driver for this device for Linux.
>> Of course I don’t have access to any documentation about how to communicate with this device (I’ve tried to contact the company making these, but my hopes are not high), so I think I will need to reverse-engineer the way the existing driver communicates with the hardware. How could I achieve this ?
>>
>
> Usually drivers map PCIe bars into the VM and read/write at certain offsets to do.. stuff. In the linux kernel we have the mmiotrace tracer in order to capture what a driver does with the hardware. You still need to interpret the trace file, but at least this should give you the raw data on what's going on. Hope that helps.

Here's a good guide on how to use mmiotrace. It's nvidia-focused, but
the same steps would apply to any driver:
https://wiki.ubuntu.com/X/MMIOTracing

Basically, start mmiotrace, load target driver, do some stuff, stop
mmiotrace, analyze the resulting trace.

We have some tooling to help with that -- envytools/rnn/demmio will
parse the mmiotrace against a given rnndb (also in envytools). You
won't be able to reuse our rnndb, but you'd be able to build up your
own. You also wouldn't be able to use demmio directly, but you could
see how it works and modify it to your hw's needs. (e.g. it waits for
a read of the "0" mmio reg to determine which chip is being traced,
and loads up the appropriate rnndb settings - that won't work with
your hw out of the box.)

>> Also, the long term goal of this project would be to have this driver merged into mainline, so what is allowed or not while doing this to avoid problematic legal ramifications ?

This isn't legal advice (for that, consult a lawyer), however a few
things that are definitely going to get you into trouble:

 - stealing (or using stolen) documentation
 - de-compiling target driver and copying its implementation (as that
would be subject to copyright)

A semi-common technique is to use a so-called "chinese firewall", e.g.
one person/team de-compiles, writes documentation, and then a second
person/team uses that documentation to implement a driver. That way no
copying of copyright-able content occurs, and no one can claim that
the implementer had access to the copyrighted materials and thus could
copy without even trying to. But it all depends on the target company
(and jurisdictions in question) -- if they're particularly litigious,
they could sue you for breathing air -- doesn't matter that their case
has no merit, you'd still be stuck defending yourself.

Cheers,

  -ilia