Nouveau - Mar 2021 - How to reverse engineer a PCI-Express driver under Linux ?

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.

> 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 ?
> Thank you for your help.
>
Best regards.
> Tomek Lecocq
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20210303/a700c630/attachment.htm>

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