I’m confused. The Atheros AR9460 wifi/BT card which ships in Librem laptops does not require non-free firmware for the wifi. It’s as free as you can get. Why would you want to replace it with another non-free card which provides no additional capability or performance?
The bluetooth component of the AR9640 does require non-free driver firmware currently, as we’re continuing to work on RE’ing that so that a completely free driver can be used.
And to add to that, I have developed a kernel patch that prevents loading of the AR3k Bluetooth firmware while still initializing the BT properly using the chip’s built in ROM firmware. I am using this for some time now and do not experience and regressions. The only problem remaining is that one still needs the config file which is part of the non free firmware (the “ramps…” file). This file does not contain actual firmware but only some settings, one of which enables the Wifi - Bluetooth coexistence in the Bluetooth chip so that it can share the antennas with the WiFi card. So without this config file the Bluetooth would work but would be be deaf. I am working with the FSF now if such a binary only config file would be OK to have / ship. If it is this would be the suggested solution to enable Bluetooth in the Librem laptops and I would work on upstreaming the kernel patch.
For everyone interested, this patch looks like this:
--- linux-4.18/drivers/bluetooth/ath3k.c 2018-09-26 08:39:43.000000000 +0200
+++ linux-4.19/drivers/bluetooth/ath3k.c 2018-11-05 07:59:24.739931449 +0100
@@ -528,18 +528,20 @@
/* load patch and sysconfig files for AR3012 */
if (id->driver_info & BTUSB_ATH3012) {
/* New firmware with patch and sysconfig files already loaded */
- if (le16_to_cpu(udev->descriptor.bcdDevice) > 0x0001)
+ if (le16_to_cpu(udev->descriptor.bcdDevice) > 0x0001) {
+ BT_ERR("ath3k patch already loaded");
return -ENODEV;
+ }
ret = ath3k_load_patch(udev);
if (ret < 0) {
- BT_ERR("Loading patch file failed");
- return ret;
+ BT_ERR("Loading patch file failed, ignoring");
+ // return ret;
}
ret = ath3k_load_syscfg(udev);
if (ret < 0) {
- BT_ERR("Loading sysconfig file failed");
- return ret;
+ BT_ERR("Loading sysconfig file failed, ignoring");
+ // return ret;
}
ret = ath3k_set_normal_mode(udev);
if (ret < 0) {
Cheers
nicole
For installing OSes like QubesOS that automatically install non-free firmware.
The thought process was that I could just swap out the non-free card and put one in that is more free’d.
The problem isn’t with the WIFI but the Bluetooth fore, my understanding is that they are provided by the same wireless card. Therefore, to disable one you must disable both.
Are you saying this is incorrect?
Cool, is there any tutorial for users who want to try implementing this?
Also, from my understanding, most users that do not want proprietary drivers for WIFI is because they can make it send more data than requested or do something malicous on the laptop.
However, because your patch enables it so that no firmware on the main storage gets installed this would not be an issue, correct?
Plus, all currently used Bluetooth and WIFI cards also contain non-free ROM firmware, correct?
There is no tutorial, I am sorry you have to rely on more experienced developers to implement that for you then.
The firmware question has nothing to do with doing “malicious” things, it has to do with freedom, security and privacy - to explain this I would need to into a lot of details and this is not the right place for it.
I can also not comment on “all Bluetooth and WiFi cards” for obvious reasons. What I can say though is that the AR3k Bluetooth chip implemented on the M.2 card in the Librem laptops comes with a built-in ROM firmware that is capable enough to be usable, which the above mentioned kernel patch enables.
Cheers
nicole
I liked the idea when reading this and already thought about testing it on my Librem.
But while thinking about it, I stumbled over the fact that the blob might not be on my disk, but instead I use a blob from my hardware. Isn’t that cheating somehow?
To think it a bit further: What gives me more control? Using the unchangable blob in my hardware or using the blob from my disk (that - taken I’d invest a lot of work - I could probably disassemble somehow to understand or change it)?
In the light of this new bluetooth issue I’d say that using an updated firmware would improve my security and using the old ROM firmware would be risky.
Yes, you are right to some extend and this argument is exactly what is currently debated with the FSF and others. The basic idea is to treat a device which contains the firmware in some form of internal storage as hardware - like some other chip which has a specified function, you get a documentation for it and you can be ind f sure that this hardware will always work the same way and can not be tweaked to do malicious things without you noticing.
But this clearly opens up the question of how to handle security updates. These “pieces of hardware” have become so ‘smart’ and complex that they are likely to have bugs and will need updates at some point - updates you really want to have to protect you. The FSF is aware of this issue and we (and others) are in discussion with them how to best cope with this - maybe by some form of change or exception for the RYF rules, we don’t know yet.
But up to now it is like it is, i.e. firmware is to be stored on the piece of hardware and the OS shall not touch it - unless the firmware is fully open and free. Reverse engineering the two files for the BT of the AR3k would be pretty awesome! This would allow the firmware download and be RYF compliant.The RAMPS file of the AR3k is, I am pretty sure about this, only a binary parameter file. The real code is in the second file that gets loaded (and which can be ignored for now). The RAMPS file has a couple of prettty regular structures which shouldn’t be too hard to rev-eng. That would be very awesome!
Cheers
nicole
Thanks a lot for the timely answer, the background information and the good work at the root of the problem!
Will there be a blogpost, if the discussion with the FSF and the upstreaming of your patch are done? 
Sure, absolutely, even before that, once we have something to report. ATM everything is pretty much “in the air” but as soon as we start have a plan or path we will for sure talk about it.
Cheers
nicole
Dear Nicole,
Any news on free bluetooth drivers for librem 13?
You announced almost a year ago that it was “in the air”. But since then, nothing …
In addition, I see a tremendous development of the product range at Purism, but think of your customers who bought the first versions and who are still waiting for a 100% release of their equipment (I am also thinking of bios) .
Thank you for your answers.
Yours,
Are there any news on this topic, @nicole.faerber? Is there some public thread somewhere public to follow?
I try to be patient… but after two years now I have to ask: do you have any news on this topic?
Yeah, hmm… very unsatisfactory, totally get it. The only kind of solution I can offer is to install the binary firmware for the ar3k Bluetooth part, I’m sorry. The problem is with the FSF and the PureOS endorsement which we have not been able to straighten out. We must not include any blobs in PureOS and we must not endorse any sources that would carry such blobs.
While I understand the goal of it and also support that this puts us into a very VERY difficult situation - and this Bluetooth issue is just the tip of the iceberg! Pretty soon we will run out of WiFi chips that will work without binary blobs! And then?
I think this binary blob firmware issue needs to be thought over. It does not fit into the current hardware world anymore. Most hardware is full of proprietary firmware but this stays unnoticed because you do not see it - starting from the touchpad to the DP-HDMI transceiver to the battery charge controller, the SD card reader etc. etc. - there are at least a dozen firmwares hidden in the laptop that are not free. But these are assumed to be “OK” since they come with the hardware, in some form. But actually by hiding them from the user this also keeps them out of control - no way to see them, analyze them or update them. For some of these firmwares this can even impose a security risk as we have seen in the past (not with Purism hardware luckily) with WiFi exploits that were only possible to fix in firmware. So hiding the firmware in some ROM can actually be harmful.
So I am wondering how we can move this forward in a reasonable way?
Of course we do not want to give up our goal to free everything! As soon as and as good as we can.
But our corridor for hardware chips not requiring firmware blobs is getting more and more narrow and for some it is close to impossible to develop free firmware. Soon we will run out of ATH9k WiFi cards and there are no chips on the market than can be used without the blob download at runtime. None, seriously, I am looking literally for years now.
With the FSF’s super strict policy we are hurting ourselves and also users by cutting us off from a lot of hardware.
So the question is what can we do to move forward?
I do not at all want to preclude anything here, there is no decision made, the following is just a very personal train of thoughts (and especially NOT a Purism policy change, OK?).
I would be in favor of rethinking the binary blob firmware situation. What is the real goal? What do we want to achieve with a blob policy? What are certain risks we want to mitigate with it? What are longer term goals? Are there possible security threats? Etc. So first bring all that on the table and then discuss possible new solutions that can address these concerns and reach these goals.
My personal view on this is…
Soon there will be no other choice than to support binary blob firmwares - or we will loose a substantial part of our functionality (like WiFi). Binary blobs in themselves are not harmful - it is the same proprietary binary if you include it in some chip or on your harddisk, does not make a difference (concerning the content and its purpose). Having the blob on storage can have security implications. It could get replaced without the user’s notice. But that could get addressed by signatures etc. Blobs in general could include code that could access main memory - think of peripherals like an integrated graphics chip which has access to main memory. We may not want to allow that, so a new rule or barrier for firmware blobs could be where it is executed and which kind of access and control the main operating system can have over that. And finally of course if such blob would need to be executed by the main CPU that also runs the operating system and applications. Here I would say is a clear red line, this would not be acceptable. Having the main CPU take the binary and shove it into some chip, maybe OK, but not execute mystery code, no way.
Something along these lines. I could see something like Debian does, having a non-free repo that contains such blobs. Plus maybe implementing a system so that a user can sign these once they land on the system, with his/her own key and that only properly signed firmware can get loaded (I think we could implement that along with a necessary chain of trust using the LibremKey). And to only provide firmware of course that are vetted against rules like “not being executed on same CPU running user software” etc.
I would be very interested in more opinions and especially the reasoning behind these!
Like to share?
Maybe with an open discussion we can develop a new set of rules that properly address concerns while keeping access to current hardware.
Cheers
nicole
Non-free firmware is a fact of life. It is just not possible to implement all functionality in hardware alone.
For me, the important thing is freedom. Freedom to be able to do with my hard- and software as I please.
If hard- and software is opensource, I do not have to fear vendor-lockin or vendor-control.
Hardware should be open so that the community can write drivers and software. If that requires non-free firmware (binary blobs) on the hardware to protect certain IP, so be it.
Thanks for sharing!
Right, I tend to agree and you bring up a good point I forgot to add to “my” set of rules:
The firmware blob must come with a perpetual license to copy, redistribute and bundle it. This is essential for the freedom you pointed out and we all want to maintain.
Cheers
nicole
For me it is a fact that it needs to be possible to update firmware where the hardware vendor expects us to do so - even if an initial version of the firmware is in a rom inside the hardware component.
If security issues arise in a specific firmware we have to be able to follow up with patches/upgrades.
This statement is completely independent of the “open, free or no source” question.
If we can agree on the above statement and the point of view that security and thereby protection of user data is more important than ideals of the FSF we’d have a starting point.
Furthermore I’d say that there are enough arguments and reasons to always try everything to comply with the strict rules of the FSF as far as possible - even if it means some compromise regarding convenience and performance.
Purism could offer various levels of ‘free’ to let the user choose between convenience and willingness to support development by using less performant or convenient products that open the pass to more freedom and openness in the future.
Some projects to look at and some unsorted thoughts:
Hi Nicole,
sorry for my late reply. I don’t know how to answer that… I’m just feeling sad. I knew that the marketing of Purism especially at the beginning was way too optimistic, sure. But still…
I know that there are a lot of binary blobs in chips, but I thought ‘no binary blobs as part of the OS’ is only the first step. I thought it might be possible to free everything – so let’s start with the OS.
I’m really getting old. This is what I feel when I read your posting. You’ve got much more insight and I have no reason to doubt your assessment.
I don’t know… I can still hope for big surprises. Maybe that is what a lot of old people do.
Cheers,
Stefan.
If enough people are interested in hardware with open-sourced firmware, will a supplier eventually be incentivized to provide such hardware?
The FSF policy on non-free firmware seems very appropriate for user freedom, and I don’t interpret the role of FSF as “realistic.” Instead, FSF has always striven to be idealistic instead of realistic. This has been the unique and vital role of FSF and RMS for a long time, to the point of many questioning the relevance of the organization and its founder because they are not realistic enough.
I don’t like the approach toward the FSF policy of, “this might be impossible right now or in the near future, so we should change the policy.”
No, FSF puts forward ideals, not “goals that are achievable with the current offerings of suppliers.” Purism has made, and continues to make, more progress toward such ideals than any other company that I know about—that progress even seems closely linked with Purism’s social purpose. Don’t give up! If not Purism, what company is better situated to pursue these ideals?
I am not trying to be critical @nicole.faerber or Purism! You have done far more for free technology than I could dream of. And you have far more knowledge about the impossibility of the situation. Even if I am naive, I only want to offer encouragement to not give up on a good ideal that will make society better and people more free 
Hi all,
thank you very much for sharing your views!
And yes, I totally share the sentiment that the FSF is absolutely needed as this idealistic party that represents a strong force everything can gravitate towards! Totally get it and agree. Actually this is also the very exact same point how I found myself defending the FSF and sometimes even RMS in some discussions - it is this uncompromising idealistic force that is needed to be present in the world.
But the reality also is that it makes it close to impossible to make products based only on these idealistic rules. There must be ways to grant exceptions somehow. These may come with penalties or such, totally fine. But they need to be there or else we will shoot ourselves in the knee with a tremendously large gun! We will cut ourselves off from current hardware.
Matter of fact is that more and more silicon’s function these days is determined by software not by silicon hardware design. The software defining it is the firmware. There are some that can be rebuilt in the open, like how we did it with the smartcard reader firmware in the Librem5. In the dev kit we used a proprietary reader chip with its proprietary firmware (though this firmware was in ROM inside the chip), in the final L5 we are using a programmable microcontroller and our free firmware.
But there are also tons of chips where this is either a lot harder or even close to impossible, for several reasons.
Let’s take Bluetooth as an example, since it is also this thread’s topic. As an early Bluetooth adopter I got in touch with pretty much the very first generation of Bluetooth hardware, at that time made by CSR - Cambridge Silicon Radio. These modules were self contained, they included the MCU driving the logic, the DSP for the radio and, last but not least, storage for the firmware. From the outside you had the Bluetooth defined host controller interface (HCI), USB and serial UART at that time. Firmware update on these was a highly proprietary thing, required special tools etc. But you did not really need it, the modules worked in HCI mode and you could develop your stack against it. But also Bluetooth became more and more complex, firmware become more complex and bugs were found, so firmware updates became necessary. Also regulations became fragmented, the 2.4GHz ISM can not be used in all regions in the same way so you need to accommodate for that in your firmware (the Bluetooth stack can not do this). Having all that fixed in silicon quickly becomes a problem, you end up with tons of SKUs of one product. No one wants this. Over the years also flash memory became much more expensive than RAM - expensive in terms of chip size. Mask programmed ROM was not an option, you need to be able to fix bugs, eventually even in the field.
So the quite natural choice for many chip makers was to drop all or most of the built-in-silicon software, add more RAM instead (saves money) and upload what is needed in its most current version right at the start of the system. This solved a lot of the pain points - you can update them easily, just replace the uploaded bits, you can configure them easily in the same way and you save a lot of cost by reducing the silicon die size and the number of SKUs. A strong incentive for the chip makers.
The same is happening in pretty every peripheral chip these days. Only very small and very well defined ones still have their firmware on chip (either masked ROM or flash) like a touchpad controller. But more and more only have a tiny bootloader in ROM that will wait for a firmware and eventually parameter data set to be handed over through the HCI, put in RAM and then being executed.
So this is what’s happening on the hardware side - on the chip level.
The internals of these specialized chips, like Bluetooth or WiFi or even these touchpad controllers, are pretty much proprietary, you do not know how they are made, what kind of CPU core they have, how they work and how they attach to the outside world. Most of them are actually protected against third party hacking by “secure bootloaders”, i.e. they will only accept signed firmware images etc. Which also kind of makes sense when thinking about radios and regulations. But this of course makes it awfully hard to hack such a chip and to put something free in there.
I don’t want to say it is impossible, but it is very very hard and takes a LOT of effort, person years of development time. If you think about Bluetooth or WiFi the radio part alone is already really really complex - modulations, decoding, traffic handling etc.
And now assume for a minute we, i.e. Purism, would heavily invest in such an effort. What would we do? We for sure are not in a position to design our own radio silicon. So we have to take something, reverse engineer it (since the original maker will for sure not give us the internal information), write that firmware with all its bits and pieces (radio handling, protocol, host interface, drivers etc.) and then what?
As soon as we publish and start to sell such a product we are basically legal bait for a hole bunch of lawsuits. First of all for reverse engineering which is not legal in all regions. Second for publishing proprietary information. Third for infringing on a metric ton of patents (by the chip maker and very likely also from hundreds of other stake holders of that technology). And fourth we would very likely by forced to use the same secure bootloader stuff to lock down the firmware loaded into the chip as the original maker due to regulation compliance, for which we, as a company, will be held liable and accountable. We must take precautions that the hardware we sell can not be used in non compliant ways (at least for radios).
This is at least my line of thinking based on what I know right now. The big problem here is that Purism is a company selling products. We are not a free software project. As a company we have additional regulations and rules to follow than a free software project.
So as long as no chip maker makes new chips with fully embedded firmware, I am so sorry, I am afraid we are out of luck. We, i.e. Purism, will not be able to fill this gap with a product. We can not, no matter how much we wished to. It is way beyond our scope - and honestly also beyond our current abilities. I am not saying it’s impossible, but you would need a huge seven figure budget just to create one of these free radio chips. And even then once you are done with that you can start all over again because customers will expect the next generation. We simply do not (yet) sell enough devices to be able to pay for that. Not even close.
So what’s left?
The only way we can continue to advance all our causes and make products is to use chips we can buy on the open market. And here, as I explained above, the definitive trend in the chip industry is not to embed firmware in these chips. Even worse all the chips I looked at, and these were a lot over the years, do no allow to load that firmware through any other channel than the host interface. There used to be some that could load it from an attached serial flash chip with which we could have built our own cards, we would have done that! But these do not exist anymore.
So here we are. There are chips for which there are also free kernel drivers but which need a firmware download through the host interface at startup. And there are no alternatives to these chips. None.
So what shall we do?
Stop selling products?
Cobble together as many (really) old parts as we can find and build outdated hardware? If you want to get an idea what this “outdated” looks like in terms of radios, look at the FSF RYF hardware page for the WiFi radios. Pretty much no 802.11ac radio there:
https://ryf.fsf.org/categories/wireless-adapters?vendor=All&sort_by=created&sort_order=DESC&page=1
The latest is the Atheros9k we are also using in our products, which is quite OK but 802.11abgn only, no 802.11ac. There are no 802.11ac chip without firmware requirement - at least as far as I know. And the Ath9k is being phased out, we already have a lot of difficulties sourcing the QCNFA222 M.2 cards. And this is just the WiFi radio.
We must find a way that
a) does not totally give up the ideals that we all want to reach some glory day and
b) gives us enough breathing room to create actual products today.
And let’s be totally clear about this too, if we do not sell quite a number of products we can not make enough money to advance anything anymore. Compared to a lot of other consumer hardware product makers we already squeeze a lot out of our margin into R&D. And even that is not even close to enough to create what would be necessary to be fully free.
The silicon industry is clearly against us. Not because they don’t like freedom as much as we do but simply because of driving their cost down and because of regulations.
Can we incentivize a maker to make something that is free enough for us? And I am not even talking about us as in Purism but the us as in “freedom lovers”. No, we can’t. Was there, tried that and failed. I talked to many of them and our market and audience is just a very tiny blip on their radar. We do not matter. A company like Qualcomm now owning Atheros owns thousands of patents on all of that and proud themselves for it. They have no intention and also no reason to make any of this “free to use”. The chips they make are made and sold in the millions. Let’s be generous and say we are a strong community of some ten thousand, oh no, be more generous and say hundreds of thousands. And let’s also very unrealistically assume all of them would commit to buy the very same chip. Even then, maybe, but only maybe, you would probably get invited to a meeting.
So not, sorry, not going to happen in the chip industry.
I don’t know how to solve this. And to be very honest with you, I am currently pretty frightened about this future to come. If we stick with the hard “no non-free firmware blobs on OS storage” requirement then we will soon run into a serious problem for which I have no solution to offer. None. The first to fall is WiFi/BT. Next could be the GPU (a reason why we can not use Ryzen and who knows how long Intel GPUs will remain blob free).
I am totally open for suggestions!
But I think we will need some form of blob enclave in userspace. I am just not sure how to make it. Right now we can not create it in any way within PureOS since this would violate the endorsement. We also do not want users to have to enter things manually to enable such a source. And if we create something like it, it needs to be compatible with other OSes too, like Qubes. A conundrum.
Cheers
nicole
I used to be very excited about RYF certification, but after looking into the details, I realized that there are many problems with it. RYF does call attention to the problem and makes people think about the blobs in their devices, but RYF certification actually discourages hardware makers from producing new RYF devices and discourages the community from working on freeing hardware.
There are certain components like CPU, GPU, WiFi, Bluetooth and cellular modem, where it simply isnt safe to have firmware which isn’t upgradable, and the FSF is being ridiculous by using ambiguous language in its RYF criteria and not answering my pointed questions as to whether proprietary firmware updates are allowed or not. I repeatedly asked the FSF to clarify its position on this point and I never got a response. The FSF can’t expect any hardware company to design and produce new RYF hardware if it probits firmware updates, because that is a security risk; but at the very least the FSF needs to clarify its position as to whether RYF certification allows updates to proprietary firmware or not. If updates are allowed, under what conditions are they allowed?