4 ms·

They don't even do microcode updates, which is ridiculous when you are running non-free microcode to boot.

by yuhong 11y ago

zokier 11y ago
Well that's the good old GNU/FSF firmware reasoning; its "better" to have the same firmware permanently burned into a chip than have it software upgradeable. Also happens to be one of the reasons I think FSF has lost its way if they ever even had it in the first place.
- yuhong 11y ago
  Fun quote from http://www.gnu.org/philosophy/free-hardware-designs.en.html http://www.gnu.org/philosophy/free-hardware-designs.en.html for example: "Any program in your computer, that someone else is allowed to change but you're not, is an instrument of unjust power over you"
tadfisher 11y ago
Is it Libreboot who is being ridiculous, or Intel/AMD? Is it worth trusting OEMs with wholesale access to your data and your networks?
- wmf 11y ago
  Is never-updated proprietary microcode somehow better than updated proprietary microcode?
  - chris_wot 11y ago
    That's a false dichotomy.
    - yuhong 11y ago
      It isn't in this case.
  - AnthonyMouse 11y ago
    In a significant sense it is. It means if it wasn't malicious from the factory then it can't be malicious now. The best security design for software-in-hardware always starts with the software being burned into ROM. Then you can pick from one of two ways to do updates. The first is the updates are received from the operating system during every boot, so removing power is a reset to factory. So if you throw the system disk in the trash and replace it with a clean one you know you have a clean system. This is in nearly every sense the best way to do it, except that you can't fix a firmware bug that exhibits before the OS boots. The second is to have some flash memory on the hardware that can be used to install firmware updates, but have a jumper that determines if the system will look there or in ROM during boot. Then if you want clean updated firmware you set the jumper to ROM, boot and install the clean firmware to the flash and then set it back the other way. The best solution is to support both and then ship the system with the jumper set to ROM. Then you can do 99% of updates automatically through the OS and in the event of a pre-boot firmware bug the affected user can still install the update manually if necessary.
jandrese 11y ago
So if Intel discovers a bug in their chip that needs to be patched with a microcode update then Libreboot users are just SOL? That can't be right.
- wtallis 11y ago
  Linux supports applying microcode updates as part of the kernel boot process, so you are not dependent on the motherboard firmware to do it and you still get the microcode loaded pretty early.
- unknownknowns 11y ago
  Yes, see this libreboot-supported laptop as an example: https://libreboot.org/docs/hcl/x200.html https://libreboot.org/docs/hcl/x200.html The X200, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. Oops.

They don't even do microcode updates, which is ridiculous when you are running non-free microcode to boot.

by yuhong 11y ago

They don't even do microcode updates, which is ridiculous when you are running non-free microcode to boot.

Well that's the good old GNU/FSF firmware reasoning; its "better" to have the same firmware permanently burned into a chip than have it software upgradeable. Also happens to be one of the reasons I think FSF has lost its way if they ever even had it in the first place.

yuhong 11y ago
Fun quote from http://www.gnu.org/philosophy/free-hardware-designs.en.html http://www.gnu.org/philosophy/free-hardware-designs.en.html for example: "Any program in your computer, that someone else is allowed to change but you're not, is an instrument of unjust power over you"

tadfisher 11y ago

Is it Libreboot who is being ridiculous, or Intel/AMD? Is it worth trusting OEMs with wholesale access to your data and your networks?

wmf 11y ago
Is never-updated proprietary microcode somehow better than updated proprietary microcode?
- chris_wot 11y ago
  That's a false dichotomy.
  - yuhong 11y ago
    It isn't in this case.
- AnthonyMouse 11y ago
  In a significant sense it is. It means if it wasn't malicious from the factory then it can't be malicious now. The best security design for software-in-hardware always starts with the software being burned into ROM. Then you can pick from one of two ways to do updates. The first is the updates are received from the operating system during every boot, so removing power is a reset to factory. So if you throw the system disk in the trash and replace it with a clean one you know you have a clean system. This is in nearly every sense the best way to do it, except that you can't fix a firmware bug that exhibits before the OS boots. The second is to have some flash memory on the hardware that can be used to install firmware updates, but have a jumper that determines if the system will look there or in ROM during boot. Then if you want clean updated firmware you set the jumper to ROM, boot and install the clean firmware to the flash and then set it back the other way. The best solution is to support both and then ship the system with the jumper set to ROM. Then you can do 99% of updates automatically through the OS and in the event of a pre-boot firmware bug the affected user can still install the update manually if necessary.

jandrese 11y ago

So if Intel discovers a bug in their chip that needs to be patched with a microcode update then Libreboot users are just SOL? That can't be right.

wtallis 11y ago
Linux supports applying microcode updates as part of the kernel boot process, so you are not dependent on the motherboard firmware to do it and you still get the microcode loaded pretty early.
unknownknowns 11y ago
Yes, see this libreboot-supported laptop as an example: https://libreboot.org/docs/hcl/x200.html https://libreboot.org/docs/hcl/x200.html The X200, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. Oops.