Hacker News new | past | comments | ask | show | jobs | submit login

> This mechanism allows anyone to twiddle the bits.

This remained unclear to me. Other comments say the CPU needs to be in red unlocked state, whatever that is.

The screenshot shows UEFI. So one could guess the CPU is in such state before the operating system gets loaded. But the operating system typically loads a microcode update, after that the CPU should no longer be in unlocked state.

So for "everyone can fiddle with the bits", that would require to run a modified bootloader first. Which should not be possible thanks to secure boot.

So yes, maybe it's a small step to another highly complex exploit. But it's not that everybody running a securely booted operating system (which should be everybody) can start fiddling with bits.

Edit: There is a difference between your own bits and someone else's bits. Yes, on your own machine you can run a modified bootloader and that's a good thing. Putting a modified bootloader to another machine should not be possible (until someone breaks secure boot, but I don't think that has publicly happened)




> So one could guess the CPU is in such state before the operating system gets loaded.

That would be an incorrect guess. Getting into this mode requires the cooperation of the ME. If you're Intel then that means you use parts with different fusing and boot some magic ME firmware that lets you do this. If you're not, you exploit a vulnerability in the ME (something that's currently only possible on older hardware) to do so. You can't enable this by simply replacing the bootloader.


> So for "everyone can fiddle with the bits", that would require to run a modified bootloader first. Which should not be possible thanks to secure boot.

Can't the bootloader be signed with MOK (machine owner key ?) that may allow this to work ? (Phys access required, no doubt)

Alternatively if the bootloader doesn't load microcode, just prevent the OS from loading microcode and the system will be in the attackable state ?


By "anyone", I mean not Intel. Previously only Intel had the private key for signed microcode updates, and no one else even knew the format of microcode. Even with control of the machine you couldn't play with the microcode or know what it did. This allows read/write access for researchers.

It's deeper than secure boot kind of stuff.


Firmware is not protected by Secure Boot. It can be protected by things like Boot Guard, but at least that one (Intel's) requires pairing the board and the CPU, so it can only be done in laptops and other prebuilt OEM systems.


What do you mean by firmware here?

Microcode? No it's not. But as long as you only load bootloaders or operating systems that are signed, it doesn't matter that they could fiddle with the bits as long as the signature guarantees they don't (in any undesired way).

Or ME? Well, that seems to be a complete security nightmare.


Microcode is protected by its own signing thing, IIUC.

Firmware is both ME firmware and x86 firmware — the UEFI implementation, FSP, everything else that runs on early boot.


If you’re not doing this as a hack but to get more control over your own processor, you can just turn off secure boot, it’s a bios setting.


Sure. But preferably install your own keys and sign bootloader and operating system yourself if you run untrusted code on the machine.


You can't install your own microcode signing key. Only intel's is provided, and it's in unmodifiable mask ROM.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: