State of bluetooth & wifi drivers in linux-libre

[Divya Ranjan]

Hello Denis,

Thank you for your elaborate response.

> The job to do to make that happen is to take the firmware binary which
is in 8051 assembler and produce source code from that.

> The good news is that the firmware is really small and that it's not
very hard to do compared to reverse engineering other WiFi firmwares.

> The bad news is that last time I looked automated tools like retdec
didn't support this CPU architecture so it might require a bit of time.

> But given the size it's probably coded in assembly directly, so maybe
that makes it easier, especially if you can at the end produce the same
binary (see below why).

Thanks a lot for this information, but would you be so kind as to share some resources on how to embark on this? This would be my first reverse engineering project, so if you have any similsr tutorials or other resources I'd be glad.

I will have enough time from this weekend for this, and since you claim this is doable, I would certainly want to push through. I've heard the major obstacles for libre kernel to be networking only, this might help in running on a few more computers since Realtek's this line of chips are actually really ubiquitous and indeed upstream Linux does have the drivers in-tree, I've tested the same chip on it.

> Once this is done the next step could be to somehow get this source
code to build and get the same binary than the one you extracted from
the driver. This is important as it could make most distributions
accept the source code without having to do a lot of source code
reviews.

Noted. But why would distributions have to worry? Wouldn't the driver and firmware be in-tree and compiled with the kernel? 

Apologies for my ignorance, if I might have said something wrong.

Regards,

Divya Ranjan


On 25 October 2024 23:28:45 GMT, Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org> wrote:
>On Sun, 20 Oct 2024 02:28:22 +0000
>Divya <divya at subvertising.org> wrote:
>> What exactly includes non-free firmware? I linked the firmware for
>> the chip that is licensed under GPLv2. I am aware that linux-libre is
>> completely free software. But the chip in question has its firmware
>> publicly available as free software. Unless I'm missing something,
>> where is the non-free firmware?
>
>Assuming upstream Linux has a driver for these, there is a way to get
>this fixed relatively easily compared to other nonfree firmwares, and
>have the firmware get included in FSDG distributions.
>
>The job to do to make that happen is to take the firmware binary which
>is in 8051 assembler and produce source code from that.
>
>The good news is that the firmware is really small and that it's not
>very hard to do compared to reverse engineering other WiFi firmwares.
>
>The bad news is that last time I looked automated tools like retdec
>didn't support this CPU architecture so it might require a bit of time.
>
>But given the size it's probably coded in assembly directly, so maybe
>that makes it easier, especially if you can at the end produce the same
>binary (see below why).
>
>So the first thing to do is to try to find a way to understand which
>parts of the firmware is code and which part is not. Maybe writing code
>to follow all instructions with radare2 or similar software could do
>that somehow. We have the address at which code starts to execute
>already.
>
>Once this is done the next step could be to somehow get this source
>code to build and get the same binary than the one you extracted from
>the driver. This is important as it could make most distributions
>accept the source code without having to do a lot of source code
>reviews.
>
>Also if I remember well there are several sections inside the firmware
>binary as there are gaps that can seen with hexdump -C. Maybe some
>zones are data or maybe there is a simplistic bootloader and then code.
>
>After that, it could be a good idea to comment a bit the source
>code and to use some meaningful names. The driver has some information
>on the communication between the driver and the firmware.
>
>So it might be possible to name the registers / memory address used to
>do this communication and they are probably easy to find as the
>constant used by the driver are also easily found inside the 8051 code,
>but I've not been able to confirm that as I didn't try to modify the
>firmware to do experiments with it. If I remember well there is some
>comments or variable / functions names about a mailbox
>communication interface in the driver somewhere.
>
>See https://libreplanet.org/wiki/Group:Hardware/Components/WiFi/Realtek for
>more details, especially this link:
>https://libreplanet.org/wiki/Group:Hardware/research/e-readers/Kobo/Aura_H2O_Edition_2#WiFi_firmware
>
>Also a difficulty here would be to understand where to stop, for
>instance it's unclear if a partially commented source code would be OK
>or not, but maybe other people can comment on that. If it's easy enough
>to comment all the source code, doing that might avoid complex
>discussions and save a lot of time.
>
>Denis.

Divya Ranjan, Mathematics, Philosophy and Libre Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20241104/29b0202f/attachment.htm>