GNU Linux-libre 5.10-gnu After A Busy Time Deblobbing

[phoron]

This is where things get horrible. Nothing says that the backed in firmware is any good. Wifi it is a case that the old firmware can in some countries have you broadcasting on wrong frequencies this can be a quite a fine for radio interference. So there are cases where old firmware is bad

Firmware is paid for with the sales of the device. Once sold, there's not much economic incentive to release better versions.
The vendor may go out of business, cease to be interested in a country when that country changes broadcasting regulations, tell you to buy a new gadget, or whatever.
Your point is valid but the consequence is you must look for devices with free firmware. Then others can fix it and adapt it to new laws, vulnerabilities, or whatever.
And if laws don't allow that, then we need better laws.

The firmware blobs Linux kernel loads do not go into eprom also none of them have any restriction against downgrading.

I'm not so sure that the restrictions aren't in the device themselves or in the firmware. I'm no expert and I could get lost in all the diffferent cases, but
I can imagine devices only accepting signed firmware or at least increasing version numbers or whatever.

The allowing the OS to load the device firmware into a ram on the card/device reduces hardware bricking risk.

And requiring that firmware in RAM to be free reduces blob proliferation risk.
Nobody is against upgradeable firmware. We just want it free. So if it is proprietary we try to buy some other hardware, and when not possible,
at least don't load it because we can't know it's good.

This bit from the libre guys really does not make sense. From a security point of view old firmware in eeprom on the card and loading old closed-source firmware binaries from the OS provides the same security risks.

Is not a lower risk, it's taking the risk just once. When you buy hardware you have to accept all the risk in whats there (firmware, but also circuits).
It's not really auditable and it could do whatever. But evry time you upgrade firmware you're taking that risk once again.
Trusting a vendor to be good once is less trust than trusting it to keep good forever.

Blocking loading closed source drivers in kernel space makes sense like the Nvidia binary blob. Going after hardware that has been designed from the ground up to have the firmware as open source as possible also makes sense.

Indeed.

Please note libre deblobing have broken some of those in the past that have open source firmware for their devices of course these are devices that need the driver to provide the firmware.

Yes, there have been mistakes, and they have been corrected like bugs get corrected in free software.
The problem is that upstream has a very different criteria, so it's either build something new with better criteria (Hurd?) and wait until it's ready,
or take all the job in upstream linux. But then you have a lot of work to correct the work done under different criteria, and sometimes some mistakes slip doing that.
You can blame linux-libre for not deblobing good enough. I can blame linux for enabling blob loading everywhere.
The point is that both projects will probably keep doing what they do.

[oiaohm]

Firmware is paid for with the sales of the device. Once sold, there's not much economic incentive to release better versions.

This is a bull argument. Devices like wifi cards are not sold once. The same chipset is sold for decades. There is a economic reason not to have to redesign the silicon.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/

You do see updated firmware appearing here for quite old devices. Yes it stops once the device ceases to be made but that can be quite a while. While device is being made and updating the firmware will not result in bricked there is reasons to keep on doing it so you can sell your product as stable and dependable in usage.

I'm not so sure that the restrictions aren't in the device themselves or in the firmware. I'm no expert and I could get lost in all the diffferent cases, but
I can imagine devices only accepting signed firmware or at least increasing version numbers or whatever.

There are very limited restrictions in the kernel.org firmware collection. Signed firmware yes that does appear. But increasing version numbers does not. Would it be good to totally fail because someone uses a older install disc or changes between windows or Linux. If you a company are putting your device firmware as OS loadable you are normally doing this to be goof proof. So the firmware restrictions are on the blobs the Linux kernel loads from disc than transfers to device are quite light on average. Please note signed is even rare.

And requiring that firmware in RAM to be free reduces blob proliferation risk. Nobody is against upgradeable firmware.

The nutcracker challenge is fairly safe process because the chip is a load firmware on init of device from the OS into device ram something the libre kernel would in fact disable at different times. Do note the BCM5719 is your normal flash chip and it has your mega warning you flash this your card can die not because there was something wrong with the firmware just because the eeprom died.

Is not a lower risk, it's taking the risk just once. When you buy hardware you have to accept all the risk in whats there (firmware, but also circuits).
It's not really auditable and it could do whatever. But evry time you upgrade firmware you're taking that risk once again. Trusting a vendor to be good once is less trust than trusting it to keep good forever.

https://www.phoronix.com/scan.php?page=news_item&px=GNU-Linux-Libre-5.7-Released

Really that idea of taking the risk once does not stack up. Vendors make mistake in their firmware and hardware at times there are blobs to fix it. What gets horrible is at times libre even removed blobs that the source code is in fact known.

There is a reality here firmware in eeprom on a device is less likely to be updated instead the driver will be coded to attempt to work around defect. Where a firmware in ram on a device is more likely to be updated. There is a very big difference in update rate for devices with firmware stored in flash on them and the ones that get firmware from the OS on device init to be stored in ram. Big difference here is the vendor is not risking device in most cases forever bricked in the firmware update process with the ram on device firmware option. Remember bricked devices equal refunds and consumer complaints that get expensive.

Yes, there have been mistakes, and they have been corrected like bugs get corrected in free software.
The problem is that upstream has a very different criteria, so it's either build something new with better criteria (Hurd?) and wait until it's ready,
or take all the job in upstream linux. But then you have a lot of work to correct the work done under different criteria, and sometimes some mistakes slip doing that.
You can blame linux-libre for not deblobing good enough. I can blame linux for enabling blob loading everywhere.
The point is that both projects will probably keep doing what they do.

The problem here is deblobing is not a safe process. Its really simple to screw up and remove something that been done to prevent a CVE and other known security faults.

Falling back to the firmware included on the card where there is a blob patching over to top majority of cases there is a security fault here. So true here be dragons really why is a vendor in most cases going to be blob patching something with PC based cards the answer horrible as it sounds is over 99% its a security fault fix.

With eeprom cards you will see a revision with a new version of the firmware with a security fault fixed and the old one not updated crossing fingers no one notices because pushing out firmware update on card to users would risk bricked so problems.

Firmware blobs with the Linux kernel is a complex mess. Lots of them are truly needed.

[phoron]

You do see updated firmware appearing here for quite old devices. Yes it stops once the device ceases to be made but that can be quite a while. While device is being made and updating the firmware will not result in bricked there is reasons to keep on doing it so you can sell your product as stable and dependable in usage.

I don't see it. Nice that you do. Pretty world you have there. In mine vendors keep a stream of ever so slightly different products churning out to try
to convince people they should buy a new shiny device, not a stable and dependable one.
And deciding the upgrade will not result in bricking takes testing for the different models that end up in market even if the silicon is the same,
and the testing is expensive so it is best avoided. It's a little pointless argument because there are different cases, but you know that principle
that if you don't pay for it you're the product. Well, if you don't pay for your firmware upgrade you're the product. The market does not work so
magically that vendors always wish well for former customers. Sometimes the business case is pushing antifeatures to them.

There are very limited restrictions in the kernel.org firmware collection. Signed firmware yes that does appear. But increasing version numbers does not. Would it be good to totally fail because someone uses a older install disc or changes between windows or Linux. If you a company are putting your device firmware as OS loadable you are normally doing this to be goof proof. So the firmware restrictions are on the blobs the Linux kernel loads from disc than transfers to device are quite light on average. Please note signed is even rare.

It's a power struggle. If you surrender your power it'll get worse. Signed is rare because the hardware doesn't always have available processing power /complexity.
It'll keep growing.

The nutcracker challenge is fairly safe process because the chip is a load firmware on init of device from the OS into device ram something the libre kernel would in fact disable at different times.

Until the free firmware is ready and some kind of whitelist can be hacked in.

Do note the BCM5719 is your normal flash chip and it has your mega warning you flash this your card can die not because there was something wrong with the firmware just because the eeprom died.

Sure, but a capacitor could also brick something. Hardware dies. It's not a reason to gamble your software rights.
But again I'm not pro or against RAM or EPROM loaded firmware. I'm against proprietary firmware and for free firmware. Only as a lesser evil for unupgradeable firmware.

The problem here is deblobing is not a safe process. Its really simple to screw up and remove something that been done to prevent a CVE and other known security faults.

I said it's not simple. It's a lot of work. Just help and report problems if you can.
The criteria is not whether there's a CVE or whether you're told the blob fixes something. The criteria is it is free or not. If it's a nonfree blob none won't be able to know it fixes the CVE anyway. VW had very clean efficient diesels, you know.

With eeprom cards you will see a revision with a new version of the firmware with a security fault

I won't see squat. I'll be told. You may believe and I may not believe.

Firmware blobs with the Linux kernel is a complex mess. Lots of them are truly needed.

Because vendors get away not freeing important software, which is the firmware that's running our businesses and our lives.
If we don't stand up to that it'll get worse. Just look at coreboot evolution from LinuxBIOS to a blob carrier. Or Android.
You stand your ground or you lose it. Or you stand it and you lose it, but I'll stand with those who stand anyway, while I can.

[oiaohm]

The market does not work so magically that vendors always wish well for former customers. Sometimes the business case is pushing antifeatures to them.

There is a stack of anti user features in eeprom firmware on devices that don't need it. Like the device being able to power up and do stuff without a driver being loaded or user doing anything to activate it.

https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-PRM-OSFC-2020

The reality even in you default x86 firmware there is stuff that really does not need to be fired up at system start up. This is attack surface problem.

It's a power struggle. If you surrender your power it'll get worse. Signed is rare because the hardware doesn't always have available processing power /complexity. It'll keep growing.

Not exactly. Signed is rare because it makes limited sense to-do it at all.

Until the free firmware is ready and some kind of whitelist can be hacked in.

That is not in libre kernel design.

Sure, but a capacitor could also brick something. Hardware dies. It's not a reason to gamble your software rights. But again I'm not pro or against RAM or EPROM loaded firmware. I'm against proprietary firmware and for free firmware. Only as a lesser evil for unupgradeable firmware.

That the problem unupgradeable firmware is not the lesser evil. Ram loaded firmware remember you have the choice not to load the firmware so leave the hardware dead if there is some security problem with the device. Eprom loaded firmware you don't get that option yes unupgradeable firmware is fairly much always in this class. This is the problem from a security point of view you need to be fore free firmware and OS loaded firmware where possible. So user can decide what features not to activate without risking frying the hardware as well as what hardware they leave absolutely dead to the world because they don't have the software (their firmware) they need to turn over.

eeprom have limited write cycles particular the cheaper ones.

The criteria is it is free or not. If it's a nonfree blob none won't be able to know it fixes the CVE anyway. VW had very clean efficient diesels, you know.

This is not exactly true. A OS loadable non free blob can be reversed you had example of this. Upgradeable to eeprom can be reversed with lots of risk of killing the hardware. Both of these reversing processes allows confirming the claims yes its a lot more work than if they gave over the source code. Please note signed firmware and source open to inspection are not exclusive either. A unupgradeable firmware this is the worse where you buy a device the firmware can be inside a soc chip that you cannot extract or inspect to see if the claimed new version of the device in fact fixed it.

Confirming that a unupgradeable code is secure when its doing lots of fancy things is next to impossible at times.

I won't see squat. I'll be told. You may believe and I may not believe.

You see this in devices with open source firmware stored on card eproms that the new revision released has the fix and the older versions never see a firmware update due to vendors not willing to take the risk of the device being bricked. These updates with OS loaded firmwares into ram on devices do see updates across the complete range of cards. We should expect closed to be the same here.

Because vendors get away not freeing important software, which is the firmware that's running our businesses and our lives.
If we don't stand up to that it'll get worse. Just look at coreboot evolution from LinuxBIOS to a blob carrier. Or Android.
You stand your ground or you lose it. Or you stand it and you lose it, but I'll stand with those who stand anyway, while I can.

Really the coreboot usage of blobs has other question you are not asking. How much is in core firmware that devices will auto fire up that does not need to be there.

Firmware issues is more than just open source vs closed source. There is attack surface area and flaw mitigation questions. Its really simple to say we will allow unupgradeable firmware because on some miss understanding that vendors don't provide this.

The ram based/os loaded firmware devices work out to be less wasteful on resources because users don't have to buy a new block of hardware just to get a firmware update to fix a flaw and vendors are more likely to put out updates.

This is where it gets complex we need to be encouraging vendors to provide both os loaded firmwares and that firmware to be open source.

Phoron big thing what is the point of having a open source firmware that you can modify/fix if when you attempt to fix the device you risk bricking it due to eeprom limited write cycles. This is a big to miss just because something is open source firmware does not mean it useful to end user.

unupgradeable firmware that was open source first saw in the early pxe boot roms this turned out to be nicely highly dangerous for the simple reason attacker can have looked at the source to the firmware found the faults and the end users can do basically nothing against it bar bin the hardware.

Sorry the arguement that unupgradeable is safe is wrong.

[phoron]

Buf. I'm tired. I think you must be a good guy and not silly, but we simply don't agree. Let's see if I pull out an answer... Sorry if I let parts unanswered, partly not to repeat answers and partly because it gets tiring...

Not exactly. Signed is rare because it makes limited sense to-do it at all.

It depends on the case. As it becomes cheap it'll be more tempting .

That is not in libre kernel design.

The deblobing is not a fully automated process. There are ways to add exceptions, and there'd be more if needed.
I don't think that'd be a huge problem.

Eprom loaded firmware you don't get that option yes unupgradeable firmware is fairly much always in this class.

Unuploadable firmware can be there whether you know it or not. Any problem that's in the firmware you can upgrade can be in firmware you can't
upgrade or even know it's there, so it's no new class of problems. The problem is that you can't really upgrade any proprietary firmware.
When you do it is really someone else who upgrades your software, you're just helping them in blind faith, you can't know what you are doing.

But I'll repeat. I'm not for EPROM and against RAM. I don't care.

eeprom have limited write cycles particular the cheaper ones.

Wow, you spend your nights upgrading and reupgrading your firmware, you vicious slut ?
I mean how limited ? 12 ?
If it was limited years of service we could talk, but limited write cycles is not a problem. There aren't thousands of versions of firmware.
It doesn't have to be upgraded at every boot. A firmware eeprom is persistent, but it is not a hard disk. You don't keep your logs there.

This is not exactly true. A OS loadable non free blob can be reversed you had example of this. Upgradeable to eeprom can be reversed with lots of risk of killing the hardware.

Hello ?
Do you really think the price of the bricked hardware is higher than the time of the skilled reverse engineer ???
I don't think we're talking of the same hardware.
Reverse engineering is not an option worth considering.
It's like saying the VW scandal is no problem because you can melt your car and build a new one from it.

Please note signed firmware and source open to inspection are not exclusive either.

Yep! You have a really good point there.
Whenever I say I want free firmware I mean I want effectively free software, not tivoized or uninstallable.
Any signing key should be under user control.
I should probably be more explicit. Thanks.

[QUOTE]
A unupgradeable firmware this is the worse where you buy a device the firmware can be inside a soc chip that you cannot extract or inspect to see if the claimed new version of the device in fact fixed it.
[QUOTE]
Any device you buy can have unupgradeable firmware inside chips. It's the baseline risk you can't avoid when you buy hardware.

Confirming that a unupgradeable code is secure when its doing lots of fancy things is next to impossible at times.

Yes, and confirming wired logic is secure is just as impossible. It's only that the malicious vendor or evil interceptor would have it easier
with firmware inside a chip that soldering wires or etching tracks.
When you buy hardware you take a trusting decision. I don't deny that. I only say you shouldn't have to take it more often.

You see this in devices with open source firmware stored on card eproms that the new revision released has the fix and the older versions never see a firmware update due to vendors not willing to take the risk of the device being bricked. These updates with OS loaded firmwares into ram on devices do see updates across the complete range of cards. We should expect closed to be the same here.

I don't understand. It may be me. Maybe I reread it later. But it sounds as EEPROM vs RAM, and I don't care.
I care for effectively free / not effectively free or upgradeable / not upgradeable.

Really the coreboot usage of blobs has other question you are not asking. How much is in core firmware that devices will auto fire up that does not need to be there.

Again not sure what you mean, option ROMs in PCI cards or so ?
That's bad, not only for freedom but also for portability, because when you plug the PCI to a POWER9 or ARM board it should work, so it shouldn't need x86 BIOS code to work.

Firmware issues is more than just open source vs closed source. There is attack surface area and flaw mitigation questions. Its really simple to say we will allow unupgradeable firmware because on some miss understanding that vendors don't provide this.

I said it's a lesser evil. It's an evil we can't rule out. We can't say we don't want unupgradeable firmware when writing a kernel.
Whatever the kernel does, the unupgradeable firmware may be there.
When writing a kernel, we can only demand freedom in the firmware the kernel can decide to load or not.
When buying hardware we can demand that it doesn't have unupgradeable firmware, maybe in a contract, but it is futile, because it is impossible, unpractical or too expensive to check and enforce.
So it's a risk you accept whenever you buy hardware.
And when your kernel doesn't upgrade proprietary firmware you're trying to force the vendor to choose between upgradeability and freedom or
getting it good enough at first shoot and keeping it secret. If there'd be enough people behind linux-libre and friends, vendors could choose to free
their firmware in order to be able to send out patches instead of reclaiming hardware when they detect their error. It's a long shot anyway.

The ram based/os loaded firmware devices work out to be less wasteful on resources because users don't have to buy a new block of hardware just to get a firmware update to fix a flaw and vendors are more likely to put out updates.

But users can't know what those updates do. What's the use ?
You can trust Microsoft and use Windows. And keep trusting as they update it. Many people do.

This is where it gets complex we need to be encouraging vendors to provide both os loaded firmwares and that firmware to be open source.

Linux libre encourages both. Add the firmware source to the linux tree and compile it during the kernel build, and linux-libre won't deblob it.
If that solution isn't general enough for effectively free firmware (maybe because of build dependencies),
then we may discuss what would work better, because that would respect the linux-libre goal, but just having linux-libre loading
anything would only encourage proprietary firmware blobs.

Phoron big thing what is the point of having a open source firmware that you can modify/fix if when you attempt to fix the device you risk bricking it due to eeprom limited write cycles. This is a big to miss just because something is open source firmware does not mean it useful to end user.

Again: I LOVE EFFECTIVELY FREE FIRMWARE LOADED FROM RAM.
EEPROM is not a requirement. EEPROM just allows the hardware to work under linux-libre without it being free (the version shipped in the device),
because linux-libre just couldn't avoid it. Proprietary firmware is never the goal of linux-libre, even in EEPROMs. The preferred option is free firmware.
But linux-libre can't avoid EEPROM or ROM firmware just as it can't avoid weak solder. That's not policy, that's fact.

unupgradeable firmware that was open source first saw in the early pxe boot roms this turned out to be nicely highly dangerous for the simple reason attacker can have looked at the source to the firmware found the faults and the end users can do basically nothing against it bar bin the hardware.

Not sure what you mean. Security by obscurity ? So linux-libre should allow loading of proprietary blobs because then that firmware wouldn't be open source vulnerable to attacks but would be a proprietary blob with the attacks built-in ?
Can't be that. I'm just tired.

Sorry the arguement that unupgradeable is safe is wrong.

That's not my argument. I don't say it's safe. Nothing is safe and anything hidden is even less likely to be safe.
My argument is that is a risk you're taking when you buy hardware. You assume upgrades would fix it and I don't assume a non-free blob fixes anything.
It's just faith.

[oiaohm]

It depends on the case. As it becomes cheap it'll be more tempting.

As it comes cheaper it does come more temping but its really simple to forget 1 cent over 100 million units is 1 million dollars. Supporting signed is extra cost.

Wow, you spend your nights upgrading and reupgrading your firmware, you vicious slut ?
I mean how limited ? 12 ?
If it was limited years of service we could talk, but limited write cycles is not a problem. There aren't thousands of versions of firmware.
It doesn't have to be upgraded at every boot. A firmware eeprom is persistent, but it is not a hard disk. You don't keep your logs there.

Cheapest eeprom is less than 3 write cycles from new. So once to write the factory testing firmware in. Once to write the final firmware in and 1 upgrade to firmware then bricked. There are devices with firmware in ram on device that have to be provided by OS that do have a few thousand versions of their firmware. This is in fact more expensive garbage level eeprom(flash) solution to make than a Ram on card with OS provide firmware solution. Flash(eeprom) in silicon area is bigger ram. Ram is bigger in silicon area than rom. This bigger silicon area equals bigger cost. The better the quality of Flash the more silicon it takes compared to ram or rom so the more expensive it is.

Do you really think the price of the bricked hardware is higher than the time of the skilled reverse engineer ???
I don't think we're talking of the same hardware.
Reverse engineering is not an option worth considering.
It's like saying the VW scandal is no problem because you can melt your car and build a new one from it.

Devices that brick are even more expensive to reverse than devices that don't. A device that can simple brick as a person attempts to work out how to works can cost a skilled reverse engineer over 1000 times more time to work out what the heck its up to.

Yep! You have a really good point there.
Whenever I say I want free firmware I mean I want effectively free software, not tivoized or uninstallable.
Any signing key should be under user control.
I should probably be more explicit. Thanks.

This is when things get horrible hard with FCC and other parties on devices. So you might have reproducible build open source firmware that you can confirm that the firmware you have is right but its signed so you cannot load your own into general market place devices. Not that I exactly like this but at least items like this audit on the firmware was possible.

Any device you buy can have unupgradeable firmware inside chips. It's the baseline risk you can't avoid when you buy hardware.

The reality is there is always some upgradeable firmware This is your boot roms of the hardware normally. But you want these as small as possible.

Yes, and confirming wired logic is secure is just as impossible. It's only that the malicious vendor or evil interceptor would have it easier
with firmware inside a chip that soldering wires or etching tracks. When you buy hardware you take a trusting decision. I don't deny that. I only say you shouldn't have to take it more often.

This is problem non upgradeable designs means you are forced to upgrade more often.

I don't understand. It may be me. Maybe I reread it later. But it sounds as EEPROM vs RAM, and I don't care.
I care for effectively free / not effectively free or upgradeable / not upgradeable.

Except you breakdown is wrong.
You have free and non free that right.

Upgradeable is not one.
1) Unlimited upgradeable/downgrade designs this is your OS provided firmware to ram devices with the not upgradeable minimised as much as possible.(this comes important)
2) Reasonable upgradeable/downgrade devices that have a decent grade of flash
3) One direction upgrade devices with decent grade of flash these are absolutely trouble making junk.
4) cheap junk upgradeable device that has one of the cheaper or the cheapest grade of flash that if vendor is only going to provide very limited firmware updates because the devices will die applying in some cases 2 user updates.

Again not sure what you mean, option ROMs in PCI cards or so ?
That's bad, not only for freedom but also for portability, because when you plug the PCI to a POWER9 or ARM board it should work, so it shouldn't need x86 BIOS code to work.

This is why unlimited upgradeable designs is important where they can be used. Lets say you have Linux and Windows on the same machine. Lets say you have a device that firmware works with the Linux driver but not with the Windows with one version of the firmware and the reverse is also true. The ram style/OS provided firmware allows you to provide the firmware to the device that matches the driver you have.

Just because the firmware is open source does not mean it cannot have quirks that argues with different drivers. There is more to this problem. The ram based firmware changes a lot more often than most people think and it does this because it can without causing problems.

[creoflux]

Got it running on my Trisquel system i'm typing this from. Working good so far.

Just curious, is it an X200 Thinkpad?

[blackiwid]

Trusting a vendor to be good once is less trust than trusting it to keep good forever.

I think it's even more than that, even if the vendor was evil the first time and had antifeatures included the longer the users use the same firmware the more likely they find out about that antifeatures and can do workarounds or block / nuke the antifeatures, like done with uefi with that tools that deactivate the antifeatures.

So even if the vendor breaks your trust in the 1 time they deliver you the firmware already, it's better to keep this version.

[blackiwid]

The problem here is deblobing is not a safe process. Its really simple to screw up and remove something that been done to prevent a CVE and other known security faults.

That depends on how many people use and work on the libre kernel vs the vanilla kernel, the more people work and report bugs on the libre kernel the more save it get's and if at some point more people work on the librekernel likely it would become the new upstream and everything get's directly developed without the non-free blobs in mind, and then the linux vanilla project would maybe start to blob the upstream libre kernel and then that would be more risky.

Also Libre is not only about security, if not at all, security is a different feature, it can be better or worse with free software, that is not the point, a nonfree software in general can have better features than a non-free alternative, like with let's say ms office, still you don't say but look it has more features so stop using the free libreoffice.

If you value freedom most and control is in freedom much more important than security. A police state is also more secure than a non-police state yet at least if you ask it in that words most people are against it.

And if you value savety more than freedom in your view why not use the vanilla kernel till the libre kernel fullfills your priorities?

[oiaohm]

I think it's even more than that, even if the vendor was evil the first time and had antifeatures included the longer the users use the same firmware the more likely they find out about that antifeatures and can do workarounds or block / nuke the antifeatures, like done with uefi with that tools that deactivate the antifeatures.

Thing you miss here the reason why you can remove some of anti-features with UEFI is a update-able eeprom. When you cannot you can be stuck with likes of miss behaving ME. You know the Intel ME fault that allows remote access to machines even when the machine appears powered down. https://github.com/corna/me_cleaner yes this here cannot work if you cannot update your core firmware.

The updateablity of the firmware on hardware is in fact important so you don't get stuck with different anti-features. There are many cases to block anti-features is make modified firmware or force usage of particular versions. This is something the libre kernel group is not taking into serous account. There excuse is we don't have time to audit the hardware. We instead go after the soft target the OS loaded blobs that are the ones the users have some control over.

That depends on how many people use and work on the libre kernel vs the vanilla kernel, the more people work and report bugs on the libre kernel the more save it get's and if at some point more people work on the librekernel likely it would become the new upstream and everything get's directly developed without the non-free blobs in mind, and then the linux vanilla project would maybe start to blob the upstream libre kernel and then that would be more risky.

Except the libre kernel end of favouring the devices with non upgrade able firmware or devices that fall back to a out of date rom on the device. So its not like libre kernel has made the non-free blobs go away in a lot of cases just is moving them so they are embedded in the hardware. This just made them less controllable by the end user.

If you value freedom most and control is in freedom much more important than security.

That the problem with libre kernel you are not getting more control you are in fact getting less control while handing over more control to code you cannot change or replace.

And if you value savety more than freedom in your view why not use the vanilla kernel till the libre kernel fullfills your priorities?

The reality is the current path the libre kernel is on it not going to meet my requirements at all. I am after control and that everything is correctly audited.