Debian Chooses A Reasonable, Common Sense Solution To Dealing With Non-Free Firmware

[oiaohm]

Resources and time are limited. Someone is going to find something a production team will have missed. This is why firmware is easily upgradable these days even if it's on a rewritable EPROM on the device. Planned obsolescence is an artificial problem separate from software maintenance though closely related in the form of withholding bug fixes for new purchases of hardware. It could be solved by a subscription program - pay us a living wage and we'll continue to offer the bug fixes. People have to eat, even FOSS developers. But I'm going to assume you want everything given to you as a freeloader from the tone of your rant.

No its not easy up-gradable on rewrite-able EPROM. All rewritable EPROM has limited write cycles some more than others the lowest write count for a re-writable EPROM is 10. Easy upgradeable is OS loaded firmware. This is small rom loader on card with ram to store the firmware. No write cycle limit here.

Do note lot of motherboards these days are including a rom loader to be able to rewrite the EPROM if a firmware update goes wrong.

The reality here is strict. There are really two valid options. ROM firmware loader/updater + ram or ROM firmware loader/update + EEPROM of some form.

The problem here you cannot have you cake and eat it. The ram option means the OS and it drivers have to provide the firmware so the device works but its the most durable option for items that do absolutely need security updates. EEPROM is the less durable option this end up discouraging sending out updates due to the write count limit. Socketing the EEPROM seams like a good idea until you look at socket failure rates vs soldered on.

Also that one of paying companies on going money to maintain the firmware only works if the company remains in business. There are many cases of people still using hardware well after the company that made the hardware is no longer in business. Subscription program could be part of the solution but I see the legally mandatory right to the source code of the firmware and keys to replace firmware if company either ceases to exist or decides not to provide updated firmware any more as the correct solution. Of course I would to say that the company has to give the updated firmware out for free if they are willing to maintain it so would allow them to run subscription model where those paying the subscription got the updated firmware and those not paying the subscription get informed they are using insecure. Yes signed firmware allows open source and subscription for firmware at the same time. Remember per device signing is possible.

[Waethorn]

No its not easy up-gradable on rewrite-able EPROM. All rewritable EPROM has limited write cycles some more than others the lowest write count for a re-writable EPROM is 10. Easy upgradeable is OS loaded firmware. This is small rom loader on card with ram to store the firmware. No write cycle limit here.

Do note lot of motherboards these days are including a rom loader to be able to rewrite the EPROM if a firmware update goes wrong.

The reality here is strict. There are really two valid options. ROM firmware loader/updater + ram or ROM firmware loader/update + EEPROM of some form.

The problem here you cannot have you cake and eat it. The ram option means the OS and it drivers have to provide the firmware so the device works but its the most durable option for items that do absolutely need security updates. EEPROM is the less durable option this end up discouraging sending out updates due to the write count limit. Socketing the EEPROM seams like a good idea until you look at socket failure rates vs soldered on.

Also that one of paying companies on going money to maintain the firmware only works if the company remains in business. There are many cases of people still using hardware well after the company that made the hardware is no longer in business. Subscription program could be part of the solution but I see the legally mandatory right to the source code of the firmware and keys to replace firmware if company either ceases to exist or decides not to provide updated firmware any more as the correct solution. Of course I would to say that the company has to give the updated firmware out for free if they are willing to maintain it so would allow them to run subscription model where those paying the subscription got the updated firmware and those not paying the subscription get informed they are using insecure. Yes signed firmware allows open source and subscription for firmware at the same time. Remember per device signing is possible.

Flashable firmware has many more write cycles than you think. Microsoft's policy is to have new "firmware" for Surface devices each and every single month. Mind you, not all of it is flashed firmware, but they can have UEFI capsule updates as often as they want. Other vendors limit their releases based on the severity of the bug. If the firmware interface restricts what the software can interact with, you don't have to worry as much about security or bug fix issues. The problem today is that concepts like UEFI make a whole C-programmed OS to exist in firmware, and for the software OS to interact in it in ungodly ways. It's layers upon layers, and a poor design, much like memory (CPU cache, with it's many levels) upon memory (RAM) upon memory (drive cache) upon memory (drive storage).

[oiaohm]

In MIDI, as in other hardware interfaces, if the firmware is abstracted entirely by way of the interface, there is no need for updates. Synthesizers don't need them. All of the samples in conventional synths are locked up in ROM as is the primary synth engine. The driver interface for GPU's should be standardized already: OpenGL, Vulkan, DirectX, etc. Move the hardware-specific driver code to the firmware and you solve the problem. There has never been a security issue with a synthesizer through MIDI commands.

MIDI does not provide direct direct memory access or with direct access to OS storage.

https://www.kaspersky.com.au/blog/equation-hdd-malware/7623/

Things get lot more complex from security side once you start having direct access to memory or storage.

Driver interface for GPUs are not standardized. Opengl. Vulkan and Direct X are all just abstraction layers. There is a driver layer under all them that converts the abstraction into what the GPU understand.

Please note you said conventional synths not all MIDI hardware synths are conventional. Yes you are right no MIDI synthesizer has had a security issue due to MIDI commands but some have totally bricked. Yes your non conventional reprogram-able MIDI hardware synths some of them have been lacking rom to be able to reset the device if something is wrong with the firmware and it happens to nuke it own eeprom. Yes it been some of these non conventional MIDI hardware synths that have end up bricked by using up all the eeprom write cycles as well.

Move hardware specific driver code into firmware mostly does not work with Vulkan and Direct X because these standards are still being changed. Opengl use to have this problem as well.

Basically there is a catch here items like Vulkan and direct X and networking yes lots of different areas the standards are not set in stone. So the physical hardware maybe able to accelerate X feature of Y standard but the board was released before X feature was added to Y standard so the firmware created when the board was created never exports the feature by the firmware API.

There are major reasons why you need to update firmware:
1)Security problems is you need to be able to update firmware.
2)Changing abstraction layers this is your Direct X and vulkan where the exposed API/ABI from the devices firmware end up not exporting everything that it need to now. With changing standards there is no way hardware vendor can have good enough view of future to get this stuff right at time of device being made.
3)Defects in firmware resulting in devices failing/miss behaving so requiring firmware replacement.

1 and 2 MIDI has mostly avoided. 3 MIDI does not. Items like GPU where the standards are changing things are absolutely not simple.

GPU area has all 3 problems
1)security faults turn up in firmware this is due to massive access with the DMA stuff even more with the direct to storage device stuff.
2) Yes the abstraction layer is always changing.
3) Defects with firmware happen this include power management mistakes that at times have been bad enough to completely kill GPU units.

Something like harddrive and storage devices have 1 and 3. So it depends on the type of device what reasons you will be needing to update firmware and how often. Devices that need firmware updated a lot the rom and ram combination is the safest. Yes brings the annoying problem that the OS has to have the firmware to send to device so device works.

[oiaohm]

Flashable firmware has many more write cycles than you think.

No my numbers were not wrong. Flashable firmware is not created all the same. Its not uncommon for storage devices flashable firmware to only be able to be done 10 times include the 2 lost to factory testing firmware and the first written at factory firmware.

I stated the worse yes that is truly 10 cycle and the best is about 100,000 for flash storage in firmware. Remember your flash storage devices are using wear leveling and smart to be able to work around defective flash. Flash firmware without management software there risks here that flash firmware on device provide to customer is dud so will have very limited write cycles. Yes you can by a flash chip that say it has 100000 and it a dud and it turns out to have 10 write cycles. This is the problem for hardware vendors and flash firmware every time you tell customers to update firmware in flash you are rolling dice betting that the firmware chips they provided are to specification. One of the reasons vendors limit their updates is the fact flash is a dice roll.

Ram has lot lower defect rate and defects with ram are normally detectable straight away before device gets to customers. Vendors are way more willing to update firmware when it uploaded by drivers into ram on hardware because this is more reliable.

The reality here people get it backwards. Yes flashable firmware might have a lot of write cycles but when do you find out the real number of write cycles flash the answer is at the point it fails to write correctly. Flash device in specification saying it has 100000 write cycles is it most likely has that number.

Microsoft's policy is to have new "firmware" for Surface devices each and every single month.

Yes they did but about 3 percent of Surface devices failed on the 15 firmware updates no where near the 100000 write cycles expected. Yes Microsoft had mandated the 100000 write cycle class flash in the requirements. Flash like it or not is a dice roll Microsoft policy magically did not change this. All vendors using flash firmware without flash controller and do lots of firmware updates have end up on some products rolling basically snake eyes and having complete product lines fail after 10 to 20 firmware updates.

[hwertz]

Back in the day when flash ROMs were common (I for instance had some older wifi cards with flash ROMs, SCSI cards flash ROMs were quite common, etc.), there were not significant problems with flash failures, these devices were not receiving 100s of updates, I doubt many were even flashed 10 times through the life of the device (some of the fancy SCSI/RAID cards with on board battery backed cache and etc. did receive quite a few updates both to fix bugs and to add features, but ordinarily one wouldn't flash every single update into it.) But, the fact of the matter is, the market has decided to prefer loading runtime firmware into RAM when possible.

I do find Debian's goal to have fully free software laudable, having the choice of having a system with open source BIOS, GPU firmware, wireless and bluetooth firmware, etc. would be lovely. But, given devices already running closed-source firmware, I don't see the distinction where having a driver load a blob into card RAM and then the driver interacting with that closed-source firmware is forbidden, while having a driver interact with potentially the exact same firmware but running out of a flash ROM is no problem. (Prism 2 wifi cards actually had this choice, you could flash updated firmware into the flash ROM, *or* have the driver load the same updated firmware into RAM on the card and it'd run the updated firmware from RAM rather than whatever firmware was in ROM.)

[Mattia_98]

IMO this is a bad thing to happen. They should have gone with the two images option. I myself use both images, depending on the situation. They already have two images one with and one without non-free firmware but they somehow decided to get rid of the free one.

[oiaohm]

Back in the day when flash ROMs were common (I for instance had some older wifi cards with flash ROMs, SCSI cards flash ROMs were quite common, etc.), there were not significant problems with flash failures, these devices were not receiving 100s of updates, I doubt many were even flashed 10 times through the life of the device (some of the fancy SCSI/RAID cards with on board battery backed cache and etc. did receive quite a few updates both to fix bugs and to add features, but ordinarily one wouldn't flash every single update into it.) But, the fact of the matter is, the market has decided to prefer loading runtime firmware into RAM when possible

At first flash roms seamed like a good idea. The two first cases that showed it was not was in fact wifi and network boot yes ipxe and related stuff before 2000 when it was not 100 percent standardized. Due to the lack of standard with boot over network back then people would end up writing to a flash rom 50 to 60 times the flash rom was rated for 100000 everything fine right the notice that you would have percentage flash roms in fact fail start at 10 writes this was wake up call that 100000 was just the most likely outcome but you could have 1 to 2 percent of batch that was only good for 10 writes and you only know when they don't work. Wifi had a case where a lot of countries were not making up mind on what wifi freq were allowed result in some cards end up with 22 firmware updates in a year and stack of failures inside warranty because stack of flash jumped off cliff.

Firmware in ram comes about how to avoid a particular problem. Then companies notice that firmware in ram with a loader rom is cheaper than having a flash chip at the same time solving this problem..

I do find Debian's goal to have fully free software laudable, having the choice of having a system with open source BIOS, GPU firmware, wireless and bluetooth firmware, etc. would be lovely. But, given devices already running closed-source firmware, I don't see the distinction where having a driver load a blob into card RAM and then the driver interacting with that closed-source firmware is forbidden, while having a driver interact with potentially the exact same firmware but running out of a flash ROM is no problem. (Prism 2 wifi cards actually had this choice, you could flash updated firmware into the flash ROM, *or* have the driver load the same updated firmware into RAM on the card and it'd run the updated firmware from RAM rather than whatever firmware was in ROM.)

Think about it Prism2 wifi card has firmware on flash rom and also support using ram based firmware you have missed something why is this important to be the case. If the flash rom bricks Prism 2 wifi card will it work the answer is yes. If you are insane you can test this by unsolder and remove the flash rom chip from the Prism 2 wifi card if you do you will notice the rom firmware loader is still there. Yes Prism 2 wifi card can be got online without its flash firmware only using the loader rom and ram. This way the Prism 2 Wifi card is resistant to flash hardware failure.

Flash failure is a horrible hard to predict problem. Anything that reduces number of writes on flash without management chip and that is not replaceable the better.

Something else to consider we have in fact evolved on since the first rom and ram firmware solutions time. With CXL and other things we are getting now there is no reason why in future we could not have a M.2 drive in the PCIe bus system holding all the firmware the cards in system need. Think about the new direct I/O stuff.

Reality we could have a PCIe standard that a card in the system ask the for the firmware storage device to send the care the firmware it need to fire up completely bipassing the OS. Remember this would allow flash writing for the storage of firmware to be moved to replaceable device with a flash management engine.

The old PCI standard and before direct to a storage device from card to acquire it firmware is not an option.

There is a fundamental problem with flash that is not a 100 percent dependable bit of media. Flash drives make this up by have flash management chips that are able to use spare ares to replace failed areas so hiding the defect.

Its really simple to miss that majority of cards that have flash firmware storage also have the option of rom and ram for firmware. Exactly why include extra ram that extra cost if flash firmware is safe. The simple horrible answer is flash firmware is not safe as you cut down cost.

Think about it safe flash you need more flash than you are going to use so that you can controller replace failed blocks of flash the reality it comes cheaper to include rom and ram solution than do this.

Personally think firmware in ram with loader rom is on cards is the way forwards of course this need to evolve a little that you don't need OS for the card to get it firmware from user replaceable storage media. CXL changes to PCIe make this possible.

Another thing to consider there are systems out there where there is the open to use full open source firmware like the powerpc TALOS systems so. I don't call it laughable goal to have a system with fully open source firmware. I do class it as laughable to think flash rom or even total non changeable firmware is solution the failure of both have been documented enough times now.

Lot of this is how to fail functional.

[oiaohm]

IMO this is a bad thing to happen. They should have gone with the two images option. I myself use both images, depending on the situation. They already have two images one with and one without non-free firmware but they somehow decided to get rid of the free one.

There was still the problem that you would use the disc with the non-free firmware on it and the disc did not end up installing any non free firmware and you believe you are using non free firmware. There has been lack of inform user what going on here as well.

[Ironmask]

IMO this is a bad thing to happen. They should have gone with the two images option. I myself use both images, depending on the situation. They already have two images one with and one without non-free firmware but they somehow decided to get rid of the free one.

This is ingenuine, the non-free disk image was near-impossible to find, you needed a guide just for tracking it down from their website.
A major complaint with Debian was, for years, nobody could find a *working* disk image, the so-called "non-free" one. Everyone was directed to the only-free disk image which works on exactly zero computers, and then they wonder why Debian doesn't work, and then go to another distro. Debian was killing itself and restricting itself to just being free labor for Ubuntu at this point. It's about time they started to consider being relevant instead of trivia.

[redgreen925]

This is ingenuine, the non-free disk image was near-impossible to find, you needed a guide just for tracking it down from their website.
A major complaint with Debian was, for years, nobody could find a *working* disk image, the so-called "non-free" one. Everyone was directed to the only-free disk image which works on exactly zero computers, and then they wonder why Debian doesn't work, and then go to another distro. Debian was killing itself and restricting itself to just being free labor for Ubuntu at this point. It's about time they started to consider being relevant instead of trivia.

It works to install a base system and boot it but does not allow full functioning of the computer if needing the firmware for anything on it. And you are correct the non-free installer was hidden away and never mentioned, so much for caring about your users they claim.