From divya at subvertising.org  Mon Nov  4 11:52:24 2024
From: divya at subvertising.org (Divya Ranjan)
Date: Mon, 04 Nov 2024 11:52:24 +0000
Subject: State of bluetooth & wifi drivers in linux-libre
In-Reply-To: <20241026012845.065c37d5@primary_laptop>
References: <877ca46oym.fsf@subvertising.org>
 <20241019185059.0d2e2319@valencia>
 <4A927812-9214-4CA3-991D-D26465C805DC@subvertising.org>
 <20241026012845.065c37d5@primary_laptop>
Message-ID: <9330EBFA-0E2D-4349-84F1-38C22633D542@subvertising.org>

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>

From GNUtoo at cyberdimension.org  Wed Nov 13 20:16:14 2024
From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli)
Date: Wed, 13 Nov 2024 20:16:14 -0000
Subject: State of bluetooth & wifi drivers in linux-libre
In-Reply-To: <4A927812-9214-4CA3-991D-D26465C805DC@subvertising.org>
References: <877ca46oym.fsf@subvertising.org>
 <20241019185059.0d2e2319@valencia>
 <4A927812-9214-4CA3-991D-D26465C805DC@subvertising.org>
Message-ID: <20241026012845.065c37d5@primary_laptop>

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20241113/d7be88d9/attachment.sig>

From GNUtoo at cyberdimension.org  Wed Nov 13 20:16:14 2024
From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli)
Date: Wed, 13 Nov 2024 20:16:14 -0000
Subject: State of bluetooth & wifi drivers in linux-libre
In-Reply-To: <C2F7C62F-D69F-4C85-B42E-D521A75D6006@subvertising.org>
References: <877ca46oym.fsf@subvertising.org>
 <20241019185059.0d2e2319@valencia>
 <4A927812-9214-4CA3-991D-D26465C805DC@subvertising.org>
 <20241020093336.01545219@valencia>
 <C2F7C62F-D69F-4C85-B42E-D521A75D6006@subvertising.org>
Message-ID: <20241026013819.7d7b3f21@primary_laptop>

On Sun, 20 Oct 2024 17:16:39 +0000
Divya <divya at subvertising.org> wrote:
> Quite a sad fact indeed. On the other hand, I wanted to ask what is
> the state of bluetooth/wifi adapters in linux-libre are most/all open
> firmware adapters supported by the kernel?
Ath9k compatible cards are still the best supported WiFi cards, some
support both 2.4GHz and 5GHz but they are WiFi N only. They are
available in PCI, PCIe (some with M2 interfaces as well), pc-card, and
also in some WiFi access point.

For WiFi USB cards, the best supported are compatible with the
ath9k_htc firmware and driver, but they are limited to 2.4 GHz only.
They also consume more power than the PCIe ones.

The biggest issue is that there is no chip that can be used on
smartphones or tablets due to too big power consumption and the
difficulty of providing PCIe on such devices.

So the way forward is to free the firmware I mentioned in my other mail
by reconstructing its missing source code.

Then for bluetooth I'm unsure if there are free firmwares that can be
used to provide bluetooth (some are available but they are meant for
security research), but some bluetooth USB keys are compatible with the
btusb linux-libre driver. 

The issue is that these keys typically have builtin firmwares (which
can sometimes even act as a keyboard/mouse to support remote
keyboards/mouse during boot).

Since WiFi looks way more crucial than Bluetooth it might be a good
idea to concentrate on that first.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20241113/aa68c058/attachment.sig>

From rynosp at talk2eo.me.uk  Sun Nov 17 19:29:21 2024
From: rynosp at talk2eo.me.uk (Ryan)
Date: Sun, 17 Nov 2024 19:29:21 +0000
Subject: Using specific mirrors with freesh
Message-ID: <f9bca710add94dbf90490b14d39d0969bfd10c84.camel@talk2eo.me.uk>

Hello,

My apologies if this is not quite the right place or if this question
may be a little obvious in its answer, but I am currently using the
freesh repo some of my devices, I also use apt-cacher-ng in order to
reduce bandwidth on the mirrors and my own connection. I have noticed
that because the freesh install and updates via apt uses a mirror list
which means that it can often come from different mirrors, which causes
apt-cacher-ng to download it mutiple times on different devices,
despite them all using the cacher as a proxy.
	My question is, can I set a specific mirror in the
/etc/apt/sources.list.d/freesh.sources file in place of the mirror-list
uri? This would also allow me to specify the deb http:/HTTPS/// url to
use ssl my apt-cache server to mirror also as i do in the main sources
list.

I thought it best to check in case altering the freesh.sources list is
not recommend in this case.

Many thanks

Ryan

From j at jxself.org  Mon Nov 18 14:46:13 2024
From: j at jxself.org (Jason Self)
Date: Mon, 18 Nov 2024 06:46:13 -0800
Subject: Using specific mirrors with freesh
In-Reply-To: <f9bca710add94dbf90490b14d39d0969bfd10c84.camel@talk2eo.me.uk>
References: <f9bca710add94dbf90490b14d39d0969bfd10c84.camel@talk2eo.me.uk>
Message-ID: <20241118064613.6f407b65@valencia>

On Sun, 17 Nov 2024 19:29:21 +0000
Ryan <rynosp at talk2eo.me.uk> wrote:

> can I set a specific mirror in the
> /etc/apt/sources.list.d/freesh.sources file in place of the
> mirror-list uri

If you want to. It does mean managing that on your own. If the mirror
goes away, or has other problems, it'll be on you to keep things
updated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20241118/7fb69acd/attachment.sig>

From freedo at linux-libre.fsfla.org  Tue Nov 19 02:03:12 2024
From: freedo at linux-libre.fsfla.org (Freedo)
Date: Mon, 18 Nov 2024 23:03:12 -0300
Subject: GNU Linux-libre 6.12-gnu
Message-ID: <ormshwx9nj.fsf@lxoliva.fsfla.org>

Hello, free world,

*waves wings*

I'm Freedo, the spokespenguin for the GNU Linux-libre project.

*yawns*

I was supposed to have let you know last night that release 6.12-gnu is
already available, but...  oops!  I slept through last night's release.
These long days in Antarctica's Summer are so disorienting...

*yawns*

git://linux-libre.fsfla.org/releases.git/
tags {scripts,sources,logs}/v6.12-gnu

The cleaning-up scripts for this release haven't been modified since
rc7, when they were first published.


Source tarballs, incremental patches, scripts, logs and compiled
packages are already available at:

- https://www.fsfla.org/selibre/linux-libre/download/releases/6.12-gnu/

- https://www.fsfla.org/selibre/linux-libre/download/freesh/ (.deb)

- https://www.fsfla.org/selibre/linux-libre/download/rpmfreedom/ (.rpm)


# Changes to the cleaning up

- neutered blob-demanding code in CPM/QE QMC SoC, Realtek 8852BE-VT
  wifi, amlogic bluetooth protocol support, amcc qt2025 phy,
  aw96103/aw96105 awinic proximity sensor, TI TLV320AIC31XX codecs

*yawns*

- updated cleaning up of Renesas xHCI controllers, and of Intel ISH
  (Integrated Sensor Hub) HID,

- updated blob names to clean up in drivers for MHI PCI host, Adreno
  620/621, r8169, Qualcomm q6v5 remoteproc, rtw8852c, rtw8922a

- dropped cleaning up of ks7010 and Intel SkyLake audio; both drivers
  were removed upstream

*yawns*

- cleaned up blob names in TI PRU am642 and Qualcomm arm64 dts files

- clean up a newly-added sourceless GPLed program whose object code is
  disguised as a sequence of hex numbers

*gulp*


# Artwork

We have two new pictures for this release!

One show me pressure-cleaning some very dirty and very big hard drives.
Cleaning them took a lot of work!
https://linux-libre.fsfla.org/~freedo/#news

The other shows me in a mirror, so it made perfect sense to place it in
the mirrors section of the website.
https://linux-libre.fsfla.org/~freedo/#mirrors

Pictures by tutor Jason Self.


# More bad news

The GPL-licensed binary-only program I mentioned in the last release,
that wasn't removed in time for upstream 6.11 despite contributors'
patches, remains there in upstream 6.12, and now it has company of
another GPL-licensed binary-only program in the same driver!

Were they LLM/ML models, they might even qualify as open source(less)!

*ba dum tss*

Meanwhile, upstream author-itarians are introducing DRM-like means to
block loading of drivers that respect users' freedoms, that users are
legitimately entitled to build and link into their running kernels.  The
intent, rather than empowering users, or respecting their freedom to
choose what hardware to use and what software to run on it, is to
strongarm developers into adopting a license that doesn't defend users'
freedoms as fiercely.
https://lore.kernel.org/lkml/20241114103133.547032-4-ukleinek at kernel.org/

Other upstream author-itarians are pushing for the kernel to tell on
you, the user, if you choose to avoid running untrusted code on your own
device, labeling your system as security-tainted.  Information about
potential security issues is good, but pushing for the installation of
untrustworthy binary blobs isn't.  If we're not careful, this
information will end up used by local and remote programs to refuse to
cooperate with us who insist in controlling our computing.
https://lore.kernel.org/lkml/7fc07eff-b4a1-4f8d-a9de-dba057d5c9c6 at intel.com/
https://jxself.org/by-any-other-name.shtml

They misrepresent as security the users' blind trust on engineers and
companies they don't seem to trust themselves.  Such blind trust makes
users vulnerable to the very providers of hardware and software.
https://www.fsfla.org/~lxoliva/#specmelt

If they really cared about users' security, they'd be providing us all
with transparency and means to defend ourselves from present and future,
known and yet-to-be-uncovered security threats, rather than blocking the
development and the installation of improved versions.  Such blocking
enables them to enshittify harder the hardware they've already sold but
wish to control as if it was still their own.
https://www.fsfla.org/~lxoliva/#Unshittify


# Upcoming anniversary

FSFLA turns 19 next weekend!

It can't accept your online donations.

But the original FSF can.  It has kindly hosted our server for some 15
years and counting, and their end-of-year fundraiser is underway.

Please support them however you can!
https://www.fsf.org/appeal


# Keeping in touch

Follow me in the Fediverse for fresh news about GNU Linux-libre.
https://mastodon.social/@freedo

My tutors jxself and lxo are also on IRC: #gnu-linux-libre on libera.chat.

There's also a mailing list you're welcome to join:
https://www.fsfla.org/mailman/listinfo/linux-libre

That was all, everyone.  Be Free! with GNU Linux-libre.

*waves wings*

*yawns*


# Rolling credits

What is GNU Linux-libre?
------------------------

  GNU Linux-libre is a Free version of the kernel Linux (see below),
  suitable for use with the GNU Operating System in 100% Free
  GNU/Linux-libre System Distributions.
  http://www.gnu.org/distros/

  It removes non-Free components from Linux, that are disguised as
  source code or distributed in separate files.  It also disables
  run-time requests for non-Free components, shipped separately or as
  part of Linux, and documentation pointing to them, so as to avoid
  (Free-)baiting users into the trap of non-Free Software.
  http://www.fsfla.org/anuncio/2010-11-Linux-2.6.36-libre-debait

  Linux-libre started within the gNewSense GNU/Linux distribution.
  It was later adopted by Jeff Moe, who coined its name, and in 2008
  it became a project maintained by FSF Latin America.  In 2012, it
  became part of the GNU Project.

  The GNU Linux-libre project takes a minimal-changes approach to
  cleaning up Linux, making no effort to substitute components that
  need to be removed with functionally equivalent Free ones.
  Nevertheless, we encourage and support efforts towards doing so.
  http://libreplanet.org/wiki/LinuxLibre:Devices_that_require_non-free_firmware

  Our mascot is Freedo, a light-blue penguin that has just come out
  of the shower.  Although we like penguins, GNU is a much greater
  contribution to the entire system, so its mascot deserves more
  promotion.  See our web page for their images.
  http://linux-libre.fsfla.org/

  If you are the author of an awesome program and want to join us in
  writing Free (libre) Software, please consider making it an official
  GNU program and become a GNU Maintainer.  You can find instructions
  on how to do so at https://www.gnu.org/help/evaluation.  We look
  forward to hacking with you! :)


What is Linux?
--------------

  Linux is a clone of the Unix kernel [...]

(snipped from Documentation/admin-guide/README.rst)