GNU Linux-libre 4.15-gnu Deblobs Two New Drivers, Drops More Upstream References

[bridgman]

I'm not sure I understand you. By once I mean when you buy the hardware. You seem to mean everytime you install the OS ?
The assumption is that the blob being a proprietary firmware you don't have much way to inspect it. If there are several
versions you can pick one and check its hash or whatever, but you can't tell differences or check what it does. Do you mean the distro
should be deciding which version of the firmware to trust ?

If the libre distro wants to only trust the HW vendor once (like they do with ROM-resident microcode) then they can pick a specific version of the microcode (typically the first one published) and stay with it through subsequent distro releases.

Each buyer of the hardware gets a different version depending on
when he buys assuming the firmware is in ROM (a new batch of hardware will have updated firmware in ROM, I guess).

Typically the ROM-resident microcode never changes - it's just the driver/OS-loaded microcode that gets updated.

If the firmware is loaded by the driver or kernel or whatever, each buyer of the hardware doesn't get whatever firmware was available at the
time he trusted the vendor to buy the hardware, but at the time someone else decided to publish a driver or distro version.
Neither the hardware buyer nor the distro or driver publisher has enough info to trust which version is good or not.
It is bad enough to have to choose without enough info, having to rely on other peoples choices would be worse, wouldn't it ?

That's why you stay with the same model as ROM-resident microcode - pick the first one released and stick with it.

I'll take it that you mean something like the hardware buyer should have some way to know which version of the blob is installed
and whether any other version is the same or not, and get to decide which version is uploaded, including the possibility of
always choosing the same version. It seems weak. A specific version might not available at a date the buyer needs reinstalling.
The buyer might be coerced to install a new version because of claimed fixes noone can independently verify.

I'm not following you. When the hardware is first launched the microcode is available in vendor-supplied files. Pick up the first version shipped at launch and stick with it. It can only go away if the infrastructure of the libre distro publisher is destroyed without backup.

The point of linux-libre is to simplify running 100% free software. You can take kernel.org linux and manually deblob what you want.
Linux-libre will never stop anyone getting their kernels elsewhere. But that is more work. what linux-libre is doing is using a understandable
criteria to decide what to include and leave out and providing the result of that decisions to others so that they only need to agree
to the criteria, not apply them by themselves. If you make the proprietary firmware loadable how do you avoid the requirement of having to
choose which version to load without any realiable info about the contents ?

Again, do like you do with ROM-resident firmware and stick with the first one released. In the worst case it might mean you need to stay with an older driver but that is still orders of magnitude better than the current "everything is broken" model. Talking specifically about GPUs, most parts never see a microcode update from launch to EOL, but all of that hardware is broken anyways on current libre distros.

But yes, you trust RAM based vendors zero times because RAM based vendors don't have any version of microcode to trust. You never know what you might get from the net to upload. They're shipping their hardware without the firmware it needs hoping you'll get it from the net.

OK, now you're just messing with me. The vendor publishes the microcode to controlled repos, and even if someone manages to hack those the images are digitally signed so that only images they publish get loaded.

That's fine if it is free and everybody can audit it. If it's a blob then it gets more complex to really trust them just once. You're trusting them for the wiring when you buy the hardware and for the firmware when you download the firmware. That's two times. You could think of shipping the hardware with a CD, but the CD might possibly be exchanged at a shop or customs and at at some point it gets more complex than just a ROM.[/QUOTE]

But it doesn't because of hashing and signing. Besides, whether you buy two things together or buy them separately it doesn't affect the amount of trust required as long as there are mechanisms in place to ensure that only valid microcode is loaded.

There is not enough information for that analysis if you don't trust proprietary software. It's just someone offloading their responsability to choose something to someone else. That is only freedom is that someone else has a chance to make an informed decision.

So don't choose - do like you do with ROM-based microcode and stick with the initial release.

I'm just saying that right now you are steering HW vendors towards non-upgradable microcode, which is generally bad for everyone.

[dungeon]

So don't choose - do like you do with ROM-based microcode and stick with the initial release.

Yes, do that and they will praise you

Some special one hardware, most mature one at the end of the cycle. That won't hurt much because it is initial because it is very mature microcode inside ROM isn't it... and of course ask for more money for that

Do it in collaboration with them on approach "if no one could change it, it is fine" and you would even get sticker and free marketing

I'm just saying that right now you are steering HW vendors towards non-upgradable microcode, which is generally bad for everyone.

As i said, try to do it on one special edition most mature hardware and see what happens That is not bad for everyone, it is special and just for these who like it

[starshipeleven]

What does this have to do with veganism?

Over-reacting to something and putting excessive limitations.

Vegetarians are the saner ones, as drinking milk/dairy products and eating eggs does not kill animals, and also a healthy habit (reducing meat consumption in general is good).

Also, if vegan diets crippled people vegans would not be slightly over-represented among elite athletes.

Actual pure vegan diet is hard to get right and can kill people (infants are more exposed to this). http://www.i-nhs.com/inhs/diet-veganbaby.html

The only way it does not is when sitting down and planning the diet well, and then in most cases you'll have to be taking supplements of various things you don't get from the diet, or when the person was raised not vegan and then switched (how long he can keep going without supplements depends from the person and from how bad is his Vegan diet).

I would compare a person's choice to go vegan to a choice to buy OpenPOWER vs x86, in a world where OpenPOWER procs and motherboards could be bought off the shelf with cash in any computer store or even fabbed on your roof or in your backyard.

OpenPower has exactly 0 drawbacks if you run opensource software (which can be recompiled), so it is more akin to vegetarianism

[phoron]

Sorry, Bridgman, you deserve a better answer than the time I have now to write. I hope this is something. Tell me if it helps, I hope I can find more time another day

OK, now you're just messing with me. The vendor publishes the microcode to controlled repos, and even if someone manages to hack those the images are digitally signed so that only images they publish get loaded.

But it doesn't because of hashing and signing. Besides, whether you buy two things together or buy them separately it doesn't affect the amount of trust required as long as there are mechanisms in place to ensure that only valid microcode is loaded.

Please remember we are starting from a vendor we don't trust and relunctantly accept to trust once. We don't trust it to write firmware but we also don't trust it to sign it.
That vendor releases are going to be signed by the vendor itself. If the vendor gets attacked, coerced, or is malicious or incompetent, it is possible that the wrong code gets signed.
It is also possible that the code gets wrongly identified by the vendor as a previous version so as to get into hardware of people prefering earlier versions.

It looks like you are thinking in another policy that trusts the vendor forever but wants to be sure none else can impersonate the vendor at any time.

Then to make what you say work for people who don't trust the vendor, you need some third party scrow (notary) that downloads each blob version each time a vendor publishes it and either stores it safely or signs it and securely publishes signatures, so you can get it or verify from the third party if you trust that third party. This is assuming the blob license even allows this scrow. It is not impossible, but it is very centralised, more organizationally complex, hard to orchestrate from linux-libre or the like...

I think the point is once firmware can be changed it becomes software and you are equally worried about it than about a proprietary app. Firmware might not be code at all, maybe just a table of voltage values or whatever, but it still is information that changes what a computer does, so free software proponents will want it free.

Another way to look at it I've sometimes heard is trying to give parties the same power. The user isn't able to edit the firmware, so the vendor shouldn't be able either, because otherwise the vendor holds unjust power over the user. The vendor is requested to either relinquish its power by puting the firmware in a ROM or somehow make it not updatable, or better, to grant the same power it has to the user by freeing the firmware. I live in a place where the social consensus is nobody should be allowed to have guns. In other places the consensus is since some people will have them, everybody should be allowed to have them. Then some societies agree to a law where a trusted third party (the police) can have guns but others can't. I think it's a bad, exaggerated analogy, but I'm caffeine depleted...

You may be used to the current market where companies withold information on what they sell because competition and consumerism is more appreciated than knowledge sharing, quality and collaboration, but that does not really go on well with free software ideals, I think. So from your "realistic" mindset, linux-libre is hard to understand. Part of linux-libre may be not accepting current reality (not as in allucinating, but as in trying to select which part of reality you face or trying to change reality).

Anyway, I hope it's obvious but I only speak for myself (I could even change my mind someday). I'm not speaking for FSF , linux-libre or anyone else. I just explain how I understand their contributions.

Edit: I'm ignoring trust issues in verifying signatures. Let's assume you have a trust chain to the vendor (or notary) as good as your trust chain to linux-libre, even if that may or may not be the case. This is not the hardest part to solve.

Edit2: (shudder) oh dear! I'm afraid I may be giving ideas to someone to come up with a blockchain peer-to-peer proprietary firmware notary scheme which is buzzword compliant and stock market candy. I feel dirty, I'm going to have a shower or something.

[oiaohm]

Really I don't agree with the libre stunt it does not help security.

But I don't agree with what vendors are doing either.

Reality when the firmware of a device requires to be signed and checksum-ed to be load a third party should not be able to run code on the device unless the blob is defective. So with signed blobs I see no real reason to keep the source code inside hidden. Having the source code to the blobs even if you cannot replace them allows drivers developers to work out why X does not work. This would be helpful for smaller open source operating systems.

Next source code open the blob could still be built and compared just unable to be signed so able to confirm that source and blob in fact match. From here how trust-able that blob would be would be provable.

My biggest worry is biggest reason quite simple why blob code is kept hidden. It that all these hardware vendors are busy doing copyright infringement on each other. Like intel using Minix inside ME without meeting the license requirements. Its one thing to say we should trust hardware vendors. I am sorry but many hardware vendors have been caught many times steeling other parties property and use it without license or against license. So are you keeping blob code hidden because its a Pandora box that would require hardware vendors to be legal if they were to open it up.

[phoron]

Let's see if I can reply to parts I ignored before...

If the libre distro wants to only trust the HW vendor once (like they do with ROM-resident microcode) then they can pick a specific version of the microcode (typically the first one published) and stay with it through subsequent distro releases.

You seem to imply the notary is the libre distro. I think this is weird since the libre distro can not be expected to deliver proprietary stuff. On one hand it burdens them with keeping track of the first version of any firmware for all possible hardware. Or burdens them to authenticate vendors (if vendors push blobs to the libre distro, but that's unlikely because any free distro needs to be forkable without a requirement to tell or register with any vendors, otherwise it wouldn't be free).
On the other hand it forces them to include content they ideologically don't agree with.

Typically the ROM-resident microcode never changes - it's just the driver/OS-loaded microcode that gets updated.

So?. I suspect I misunderstand you. Are you saying nonmodifiable code is "typically" not modified and modifiable code is ?
That'd be tautological. We're talking which code should be in ROM or updatable, or which should be free.
I can believe code which can be modified will be modified. That's more or less a corollary of Murphy's law, because
no code is perfect. It still requires trust on who modifies it, because others can't know whether a modification gets
it closer or further from perfection.

That's why you stay with the same model as ROM-resident microcode - pick the first one released and stick with it.

I'm not following you. When the hardware is first launched the microcode is available in vendor-supplied files. Pick up the first version shipped at launch and stick with it. It can only go away if the infrastructure of the libre distro publisher is destroyed without backup.

Too much burden on the libre distro and downstream for a material we're assuming can't be trusted, isnt' it ?

Again, do like you do with ROM-resident firmware and stick with the first one released. In the worst case it might mean you need to stay with an older driver but that is still orders of magnitude better than the current "everything is broken" model. Talking specifically about GPUs, most parts never see a microcode update from launch to EOL, but all of that hardware is broken anyways on current libre distros.

"Everything is broken" is a consequence of the vendor having the policy users should trust them always and linux-libre having another policy.
You're advocating for the distro to trust the vendor (once?) but anyone can instead advocate for the vendor to trust the distro and put the firmware
in ROM or free it. "Everything is broken" does not tell who broke it.

I understand that from the point of view fo a vendor trying to cater to both potential customers that trust them always and potential customers that will at most trust them once, it makes sense to have a single approach for both. But that's hardly the only point of view there is. It's not even the only sane point of view there is. it might be the only economically feasible point of view the vendor will consider. So be it.

You could put the blame on the vendor too. It could build hardware that has the firmware in a ROM and a "shadow RAM" that can load it from the ROM or from the OS. In a libre distro, the OS won't load anything so the hardware will take it from the ROM. In other OSes the OS can load the firmware to "shadow" RAM and get newer versions. The only problem with this approach is that it does not motivate the vendor to properly test the firmware as much as if there is only ROM and no "shadow" RAM. It can still ship poorly tested firmware in ROM and improve it later if most of their customers use OSes that apply updates. That's bad for libre users (but not worse than RAM only hardware).

So don't choose - do like you do with ROM-based microcode and stick with the initial release.

If you don't really trust the vendor, knowing what is really the initial release for all vendors is too much work for too many people.
This is an information the vendor has, not an easy to have information for people who don't trust them and don't monitor them constantly.

I'm just saying that right now you are steering HW vendors towards non-upgradable microcode, which is generally bad for everyone.

Yes, I understand your view. I'm just trying to make the case that in other views this might be the lesser evil. Ideally firmware should be free, else
it should be "hardware" (non modifiable). Being modifiable and not auditable is just too bad. And this (modifiability) is a property
of the hardware, not of the firmware. If this is a requirement too few of the vendor's customers have and it really costs too much to implement,
then the only solution is having more customers caring. Linux-libre makes it easier for customers caring by making it obvious which hardware
works from this mindset.

[OneBitUser]

"This is in line with our goal of not leading users to non-Free Software."

Users?!
Does anybody use this?
Is it even possible?

[oiaohm]

Yes, I understand your view. I'm just trying to make the case that in other views this might be the lesser evil. Ideally firmware should be free, else
it should be "hardware" (non modifiable). Being modifiable and not auditable is just too bad. And this (modifiability) is a property
of the hardware, not of the firmware. If this is a requirement too few of the vendor's customers have and it really costs too much to implement,
then the only solution is having more customers caring. Linux-libre makes it easier for customers caring by making it obvious which hardware
works from this mindset.

From a security point of view everything should be auditable. Ok auditable does not mean you have the rights to change anything.

The rom it or free it I disagree with. Just because something is in a unchangeable rom does not mean its a not a massive security hole and is not an area doing copyright infringement.

My point of view is please show us that what you are doing is secure and what you are using is not nicked from someone. There have been enough cases of silicon vendors stealing source and ip from other parties and attempting to hide the fact behind trust us.

[Kayote]

I never could run linux libre, I tried several versions, even before when I had an FX6300. I can't get past the firmware loading. I tried compiling the new firmware and run into problems, can anyone provide a free firmare binary?? (I'm referring to the free firmware from FSF). Tried to get help in the mailing list they don't seem too responsive.

[bridgman]

Sorry, Bridgman, you deserve a better answer than the time I have now to write. I hope this is something. Tell me if it helps, I hope I can find more time another day

No worries, my last response had to be time-limited as well.

Please remember we are starting from a vendor we don't trust and relunctantly accept to trust once. We don't trust it to write firmware but we also don't trust it to sign it.
That vendor releases are going to be signed by the vendor itself. If the vendor gets attacked, coerced, or is malicious or incompetent, it is possible that the wrong code gets signed. It is also possible that the code gets wrongly identified by the vendor as a previous version so as to get into hardware of people prefering earlier versions.

The wrong version could get built into the ROMs as well, although I agree the vendor might test more (and charge more) if they knew that updating was not an option.

It looks like you are thinking in another policy that trusts the vendor forever but wants to be sure none else can impersonate the vendor at any time.

Not really, just the same kind of "trust once" as with ROM-resident microcode.

Then to make what you say work for people who don't trust the vendor, you need some third party scrow (notary) that downloads each blob version each time a vendor publishes it and either stores it safely or signs it and securely publishes signatures, so you can get it or verify from the third party if you trust that third party. This is assuming the blob license even allows this scrow. It is not impossible, but it is very centralised, more organizationally complex, hard to orchestrate from linux-libre or the like...

It's not clear to me how "leaving it in" could be any harder to orchestrate than "finding it and removing it"

Seriously, there is a tiny bit more work associated with confirming that microcode does not change from one libre distro release to the next, but someone has to do it if you aren't going to trust the vendor. Again this all seems so bizarre because you *do* trust the vendor not to change anything when they burn the microcode into ROM. Maybe a third party escrow would help, but then you still have the problem of ensuring reliable transport from escrow to distro - and you may end up increasing risk rather than decreasing it. I don't see what is so hard about doing a binary compare against what you shipped in the previous release. It takes time but no more time than deleting the file each time.

I think the point is once firmware can be changed it becomes software and you are equally worried about it than about a proprietary app. Firmware might not be code at all, maybe just a table of voltage values or whatever, but it still is information that changes what a computer does, so free software proponents will want it free.

I realize there is an "if a tree falls in a forest..." aspect to this, but I have a tough time understanding the difference between microcode that is fixed by virtue of being burned into ROM and microcode that is fixed by virtue of a distro-level decision not to pick up newer microcode files if the vendor releases them.

Another way to look at it I've sometimes heard is trying to give parties the same power. The user isn't able to edit the firmware, so the vendor shouldn't be able either, because otherwise the vendor holds unjust power over the user. The vendor is requested to either relinquish its power by puting the firmware in a ROM or somehow make it not updatable, or better, to grant the same power it has to the user by freeing the firmware. I live in a place where the social consensus is nobody should be allowed to have guns. In other places the consensus is since some people will have them, everybody should be allowed to have them. Then some societies agree to a law where a trusted third party (the police) can have guns but others can't. I think it's a bad, exaggerated analogy, but I'm caffeine depleted...

Perfect analogy, since I live in Canada where most people are allowed to have firearms but only after some fairly tight checks and controls, rather than "everyone has them" or "nobody has them". The point I'm making is that if the libre distros lock down on one version of vendor microcode then they *have* equalized the power, at least for users of their distro, since the vendor loses their power to update the microcode on the user's system. That's the nice thing about RAM-resident microcode - the choice to update it is made by the distros, not by the vendor.

You may be used to the current market where companies withold information on what they sell because competition and consumerism is more appreciated than knowledge sharing, quality and collaboration, but that does not really go on well with free software ideals, I think. So from your "realistic" mindset, linux-libre is hard to understand. Part of linux-libre may be not accepting current reality (not as in allucinating, but as in trying to select which part of reality you face or trying to change reality).

Not really - I do understand and value what the libre linux distros are doing; I just think they are following some outdated and overly simplistic doctrine.

Anyway, I hope it's obvious but I only speak for myself (I could even change my mind someday). I'm not speaking for FSF , linux-libre or anyone else. I just explain how I understand their contributions.

Yep... understood and appreciated.

Edit: I'm ignoring trust issues in verifying signatures. Let's assume you have a trust chain to the vendor (or notary) as good as your trust chain to linux-libre, even if that may or may not be the case. This is not the hardest part to solve.

Edit2: (shudder) oh dear! I'm afraid I may be giving ideas to someone to come up with a blockchain peer-to-peer proprietary firmware notary scheme which is buzzword compliant and stock market candy. I feel dirty, I'm going to have a shower or something.

LOL !

You seem to imply the notary is the libre distro. I think this is weird since the libre distro can not be expected to deliver proprietary stuff.

Why not ? They support and recommend hardware with proprietary microcode burned into ROM - drawing the line at redistribution is like saying that killing an animal for meat yourself is bad but buying the meat at the supermarket in a little white plastic foam tray is fine. Hey, my hands are clean.

On one hand it burdens them with keeping track of the first version of any firmware for all possible hardware. Or burdens them to authenticate vendors (if vendors push blobs to the libre distro, but that's unlikely because any free distro needs to be forkable without a requirement to tell or register with any vendors, otherwise it wouldn't be free).

Agreed, but copying a stable version each time is no more work than deleting the file each time.

On the other hand it forces them to include content they ideologically don't agree with.

Yeah, I do have some sympathy for that part of the discussion. One solution discussed earlier was having each vendor publish compatible repos with packages containing only their microcode, rather than having to download a non-free package containing hundreds or thousands of different images.

So?. I suspect I misunderstand you. Are you saying nonmodifiable code is "typically" not modified and modifiable code is ?
That'd be tautological. We're talking which code should be in ROM or updatable, or which should be free.

I was responding to your comment suggesting that vendors shipping ROM-based microcode would periodically update the ROM-based microcode in their production line. I was just saying that even though HW vendors could do that my impression was that most of them did not.

I can believe code which can be modified will be modified. That's more or less a corollary of Murphy's law, because no code is perfect. It still requires trust on who modifies it, because others can't know whether a modification gets it closer or further from perfection.

If the microcode is distributed in files then the decision to update is in the distro's hands rather than the vendor's hands. A simple binary compare will tell if anything has changed.

Too much burden on the libre distro and downstream for a material we're assuming can't be trusted, isnt' it ?

It's pretty much zero burden, and no more burden than deleting the file, so I would not say "too much" - in fact it's exactly the kind of integration work that distro packagers normally perform.

"Everything is broken" is a consequence of the vendor having the policy users should trust them always and linux-libre having another policy.

Nope... "everything is broken" is a consequence of the vendor giving distros the ability to update or not, and the libre distro choosing to delete instead.

You're advocating for the distro to trust the vendor (once?) but anyone can instead advocate for the vendor to trust the distro and put the firmware
in ROM or free it.

That suggests hiding microcode in ROM with no way to tell if it is changing is somehow better than delivering the microcode as a separate object where it is easy to identify changes. The only real argument in favour of ROM-resident microcode is the one related to "including content they idealogically don't agree with", which seems kind of hypocritical if they are also recommending hardware with even more microcode and less visibility into whether the microcode changed.

"Everything is broken" does not tell who broke it.

Right. That's where I come in

I understand that from the point of view fo a vendor trying to cater to both potential customers that trust them always and potential customers that will at most trust them once, it makes sense to have a single approach for both. But that's hardly the only point of view there is. It's not even the only sane point of view there is. it might be the only economically feasible point of view the vendor will consider. So be it.

You could put the blame on the vendor too. It could build hardware that has the firmware in a ROM and a "shadow RAM" that can load it from the ROM or from the OS. In a libre distro, the OS won't load anything so the hardware will take it from the ROM. In other OSes the OS can load the firmware to "shadow" RAM and get newer versions. The only problem with this approach is that it does not motivate the vendor to properly test the firmware as much as if there is only ROM and no "shadow" RAM. It can still ship poorly tested firmware in ROM and improve it later if most of their customers use OSes that apply updates. That's bad for libre users (but not worse than RAM only hardware).

It also makes the hardware more expensive for everyone. It's tough to justify loading that cost onto all customers when EXACTLY the same result (with more visibility) can be obtained by having distros that don't want to trust vendor microcode updates to lock onto a single version.

If you don't really trust the vendor, knowing what is really the initial release for all vendors is too much work for too many people. This is an information the vendor has, not an easy to have information for people who don't trust them and don't monitor them constantly.

The initial release is the version that comes out first

Seriously, for a new libre distro I think any vendor would be willing to work with them to identify either "the first" or "the recommended" microcode version. Since the goal of the exercise is only to deny the vendor the ability to perform uncontrolled microcode updates going with "recommended" would probably make most sense in the rare case where there are post-launch updates.

Yes, I understand your view. I'm just trying to make the case that in other views this might be the lesser evil. Ideally firmware should be free, else it should be "hardware" (non modifiable). Being modifiable and not auditable is just too bad. And this (modifiability) is a property of the hardware, not of the firmware.

This is what I just don't get. Modifiability is a property of the HW/SW/distro system, not just the hardware. Blocking updates at a hardware level is only one option.

You only have auditability with file-based microcode, not with ROM-based. If anything the wrong hardware is being blocked based on that logic.

If this is a requirement too few of the vendor's customers have and it really costs too much to implement, then the only solution is having more customers caring.

Sure, but make sure they are caring about the right thing. Driving more microcode into ROM means you lose auditability and don't gain anything. The last thing you want is more people caring about *that*.

Linux-libre makes it easier for customers caring by making it obvious which hardware works from this mindset.

Yes, it cripples hardware from vendors which offer their users a choice, and supports hardware from vendors which hide the microcode in ROM with no ability to audit (or reverse engineer, if it comes to that).

It makes the message obvious, but the message is the exact opposite of what free software advocates should be sending.