5 ms·

All these intransparent layers of low-level software (microcode, management engine code, device firmware blobs) are a nightmare from a security, reliability and

All these intransparent layers of low-level software (microcode, management engine code, device firmware blobs) are a nightmare from a security, reliability and maintainability point of view.

aetherspawn 5y ago
They need to be held accountable for performance regression at this scale if they don’t provide BIOS options to switch back.
- BeeOnRope 5y ago
  If you apply your microcode using the OS loader (as described in the post), you can switch back to any microcode (which is at least as new as your BIOS version) by rebuilding the initramfs with the microcode of your choice and rebooting.
  - aetherspawn 5y ago
    How do I do this on a Windows workstation with stock BIOS/boot loader though? Who knows how much slower this machine, that I wait for 5-6 hours per day, has gotten in the last few years. IMO whoever flashes the patch should be responsible for giving a toggle.
    - floatboth 5y ago
      https://www.reddit.com/r/overclocking/comments/enm8yj/how_to_actually_disable_intel_and_amd_microcode/ https://www.reddit.com/r/overclocking/comments/enm8yj/how_to...
  - nix23 5y ago
    And under Windows with the VMware CPU Microcode Update Driver.
marcan_42 5y ago
This is purely an artifact of poor system design. x86 platforms are notoriously bad at this. I'm reverse engineering the Apple M1 and haven't found any trustability issues yet (besides the proprietary early stage bootloaders, but everything has that). There are some 12 or so coprocessors running proprietary firmware, but all of them are safely behind OS-controlled IOMMUs and not privileged to take over the system. There is no ME, no SMM, no TrustZone, nothing running with higher privilege than the OS. Most of the coprocessors have at least inspectable firmware (except the Secure Enclave, but you can just turn it off). The ARM architecture design makes it near impossible for an early boot backdoor to, say, run your OS in an undetectable VM too. No updatable microcode. On x86 you have the ME running secret code with higher privilege than the main CPU, as well as SMM running secret code on the main CPU at a higher privilege than the OS and stealing cycles from it, as well as a rather poor track record of proper IOMMU sandboxing (especially for anything that isn't a PCI device), and secret, encrypted microcode updates.
- johndoe0815 5y ago
  Thanks for your hard work! I'm looking forward to read more about your findings (and to running alternative OSes on the M1).
- floatboth 5y ago
  > SMM running secret code on the main CPU Well, not secret if running coreboot… I'm not sure if coreboot's SMM handler might call into FSP/AGESA though.
- KirillPanov 5y ago
  > I'm reverse engineering the Apple M1 and haven't found any trustability issues yet ... except for assuming "EL3 seems to be missing" means "EL3 doesn't exist" instead of "the bootrom dropped to EL2 before we got control". Not saying I have any evidence to the contrary, nor is this in any way a criticism of your awesome work. Just saying that this will unfortunately remain forever unknowable unless Apple decides to volunteer information. Personally, if I were Apple, instead of removing EL3 I would've left it in but unused, accessible only to code signed by Apple with the public key burned into silicon. As a way to mitigate currently-undiscovered silicon bugs.

All these intransparent layers of low-level software (microcode, management engine code, device firmware blobs) are a nightmare from a security, reliability and maintainability point of view.

aetherspawn 5y ago

They need to be held accountable for performance regression at this scale if they don’t provide BIOS options to switch back.

BeeOnRope 5y ago
If you apply your microcode using the OS loader (as described in the post), you can switch back to any microcode (which is at least as new as your BIOS version) by rebuilding the initramfs with the microcode of your choice and rebooting.
- aetherspawn 5y ago
  How do I do this on a Windows workstation with stock BIOS/boot loader though? Who knows how much slower this machine, that I wait for 5-6 hours per day, has gotten in the last few years. IMO whoever flashes the patch should be responsible for giving a toggle.
  - floatboth 5y ago
    https://www.reddit.com/r/overclocking/comments/enm8yj/how_to_actually_disable_intel_and_amd_microcode/ https://www.reddit.com/r/overclocking/comments/enm8yj/how_to...
- nix23 5y ago
  And under Windows with the VMware CPU Microcode Update Driver.

marcan_42 5y ago

This is purely an artifact of poor system design. x86 platforms are notoriously bad at this. I'm reverse engineering the Apple M1 and haven't found any trustability issues yet (besides the proprietary early stage bootloaders, but everything has that). There are some 12 or so coprocessors running proprietary firmware, but all of them are safely behind OS-controlled IOMMUs and not privileged to take over the system. There is no ME, no SMM, no TrustZone, nothing running with higher privilege than the OS. Most of the coprocessors have at least inspectable firmware (except the Secure Enclave, but you can just turn it off). The ARM architecture design makes it near impossible for an early boot backdoor to, say, run your OS in an undetectable VM too. No updatable microcode. On x86 you have the ME running secret code with higher privilege than the main CPU, as well as SMM running secret code on the main CPU at a higher privilege than the OS and stealing cycles from it, as well as a rather poor track record of proper IOMMU sandboxing (especially for anything that isn't a PCI device), and secret, encrypted microcode updates.

johndoe0815 5y ago
Thanks for your hard work! I'm looking forward to read more about your findings (and to running alternative OSes on the M1).
floatboth 5y ago
> SMM running secret code on the main CPU Well, not secret if running coreboot… I'm not sure if coreboot's SMM handler might call into FSP/AGESA though.
KirillPanov 5y ago
> I'm reverse engineering the Apple M1 and haven't found any trustability issues yet ... except for assuming "EL3 seems to be missing" means "EL3 doesn't exist" instead of "the bootrom dropped to EL2 before we got control". Not saying I have any evidence to the contrary, nor is this in any way a criticism of your awesome work. Just saying that this will unfortunately remain forever unknowable unless Apple decides to volunteer information. Personally, if I were Apple, instead of removing EL3 I would've left it in but unused, accessible only to code signed by Apple with the public key burned into silicon. As a way to mitigate currently-undiscovered silicon bugs.