When it comes to non-free firmware I think there's two reasonable positions - treat it like non-free code running on a remote system (suboptimal, outside the scope of current free software priorities) or treat it like software running on the primary CPU (all code on the local system should be free software, no matter where it's running). I think the FSF's position is unreasonable: https://mjg59.dreamwidth.org/70895.html
@mjg59 >Freedom isn't necessary.
Well there it is.
Unlike a PCIe Wi-Fi card, remote network servers don't have DMA access to the main memory space (IOMMU is a pretty shoddy workaround).
Microcode in ROM in an intel CPU is hardware circuits that don't have a proprietary software license attached to it that restricts you and you do have the right to do whatever you want to your own hardware - even to sell it.
As far as I can tell, the microcode in ROM doesn't contain malicious circuits, as intel knows that a decapping enjoyer is going to take a look eventually and report on any found malicious circuits.
Meanwhile, microcode updates are software, with nasty proprietary license terms that require acceptance and this line from the software license confirms that the updates are partially proprietary malware;
>3. No reverse engineering, decompilation, or disassembly of this software is permitted.
That's right "reverse engineering our updates and finding the malware is not allowed, even though we've made every effort at doing so extremely difficult with encryption and an undocumented instruction set and only around a dozen people knowing how microcode updates work".
All software running on a computer should be free and I am working towards achieving that.
Encouraging the user to accept a proprietary license for proprietary peripheral software only leads the user away from freedom, as such software almost never gets replaced (there are arguments that RAM loaded proprietary software is easier to replace than EEPROM installed proprietary software, but for some reasons EEPROM installed proprietary software gets replaced much more often? (maybe it's something to do with how the RAM loaded software often has license terms and digital handcuffs that try to prevent replacement, while EEPROM included software on peripheral devices usually has no such restrictions)).
Well there it is.
Unlike a PCIe Wi-Fi card, remote network servers don't have DMA access to the main memory space (IOMMU is a pretty shoddy workaround).
Microcode in ROM in an intel CPU is hardware circuits that don't have a proprietary software license attached to it that restricts you and you do have the right to do whatever you want to your own hardware - even to sell it.
As far as I can tell, the microcode in ROM doesn't contain malicious circuits, as intel knows that a decapping enjoyer is going to take a look eventually and report on any found malicious circuits.
Meanwhile, microcode updates are software, with nasty proprietary license terms that require acceptance and this line from the software license confirms that the updates are partially proprietary malware;
>3. No reverse engineering, decompilation, or disassembly of this software is permitted.
That's right "reverse engineering our updates and finding the malware is not allowed, even though we've made every effort at doing so extremely difficult with encryption and an undocumented instruction set and only around a dozen people knowing how microcode updates work".
All software running on a computer should be free and I am working towards achieving that.
Encouraging the user to accept a proprietary license for proprietary peripheral software only leads the user away from freedom, as such software almost never gets replaced (there are arguments that RAM loaded proprietary software is easier to replace than EEPROM installed proprietary software, but for some reasons EEPROM installed proprietary software gets replaced much more often? (maybe it's something to do with how the RAM loaded software often has license terms and digital handcuffs that try to prevent replacement, while EEPROM included software on peripheral devices usually has no such restrictions)).
@Suiseiseki Microcode in an Intel CPU is not hardware circuits - it's software. Pretending otherwise is dishonest. When you power on an Intel CPU it runs code out of ROM that performs a series of operations (including performing cryptographic validation of other blobs) before jumping to the reset vector. And, well, good luck making the argument that there's no license associated with that - would you argue that a copy of Linux in ROM creates no GPL obligations?
@Suiseiseki (And, indeed, Intel v. NEC established that microcode was copyrightable all the way back in the 80s!)
@mjg59 >it's software
The circuits are circuits that are hardware, even though they happen to encode microprocessor instructions.
>(including performing cryptographic validation of other blobs)
If you don't include any proprietary software on core 2 duo's, such cryptographic validation is not done.
>would you argue that a copy of Linux in ROM creates no GPL obligations?
There would be no obligation under the GPLv2 to provide installation information, but the source code would need to be provided.
The circuits are circuits that are hardware, even though they happen to encode microprocessor instructions.
>(including performing cryptographic validation of other blobs)
If you don't include any proprietary software on core 2 duo's, such cryptographic validation is not done.
>would you argue that a copy of Linux in ROM creates no GPL obligations?
There would be no obligation under the GPLv2 to provide installation information, but the source code would need to be provided.
@Suiseiseki The only way that source code distribution could be required is if software licenses can apply, so why do you think that would apply to Linux in mask ROM but not Intel microcode?
@mjg59 You do not need a license to operate hardware.
The user does deserve the source code to the hardware microcode, alas Intel does not provide it.
The user does deserve the source code to the hardware microcode, alas Intel does not provide it.
@Suiseiseki But microcode is copyrightable software, as established in decades-old case law.
@mjg59 I don't really care about what bizarre conclusion a court arrived at decades ago, as the conclusion is not applicable to operating hardware.
@Suiseiseki Your claims are simply wrong. Microcode doesn't change state simply because it's embodied in ROM - its copyrightability isn't related to the physical layout of gates, it's related to be functionality they embody (ie, if I were to encode the same microcode in a different physical layout, it would still be a copyright violation). It's software, it can (for good or bad) be bound by software licenses. In the US, first sale doctrine likely still applies, but other restrictions may exist.