Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undocumented x86 instructions in Intel CPUs that can modify microcode

twitter.com

Post reply on HN
Print view View original

131–140 of 145 posts

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#131

Post by mjg59 »

chasil wrote: post #103
mjg59 wrote: post #43

Earlier quoted context omitted.

Sure, which is why this is useful to researchers. But the access someone needs to your system in order to exploit the ME vulnerabilities is sufficiently extreme that if someone achieves it you probably have other things to worry about.

Am I correct in surmising that a successful run of me_cleaner will prevent the abuse of these instructions?

No. me_cleaner reduces the amount of code running on your ME, and as such reduces the attack surface presented by the ME. But anyone with physical access (which is required for the interestingly exploitable ME vulnerabilities) is in a position to just put whatever ME firmware they want on your system.

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#132

Post by [deleted] »

mjg59 wrote: post #130
aasasd wrote: post #128

Earlier quoted context omitted.

I suppose one possible scenario is: - Police confiscate your laptop on some bogus pretext, then return it to you saying you're free to go. - You open the laptop and find nothing that shouldn't be there. You wipe it, reinstall the OS and continue using the laptop. - Surprise! The CPU now works for the police, so after some time it installs a rootkit or whatever. Dunno if the microcode is big enough to do this kind of…

Situation without this CPU feature: Cops compromise the ME, disable Boot Guard, compromise your firmware, backdoor your OS directly Situation with this CPU feature: Cops compromise the ME, disable Boot Guard, compromise your firmware, backdoor your CPU so it can later backdoor your OS There's not really a meaningful difference between these! If there's an exploitable ME vulnerability then the police can absolutely ow…

[deleted]

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#133

Post by mjg59 »

usr1106 wrote: post #70
monocasa wrote: post #66

Earlier quoted context omitted.

The previous publicly known mechanism required signed updates. This mechanism allows anyone to twiddle the bits.

> 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…

> 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.

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#134

Post by the_only_law »

userbinator wrote: post #62

Look up "Intel VISA" if you want to go down one of the many rabbitholes of undocumented x86... it makes me sad that there are whole subsystems in the hardware whose documentation is not publicly available; not from the security perspective, but from the "I bet someone could do some really interesting things with this functionality" perspective, like what LOADALL enabled (unreal mode, real-mode paging, etc.) decades a…

Welp, I went down that rabbit hole.

I will say, the thing security researchers find are simply amazing to me

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#135

Post by tinus_hn »

compiler-guy wrote: post #110
tinus_hn wrote: post #73

Earlier quoted context omitted.

For the 6502 there were manuals that detailed how many clock ticks every instruction takes and what happens during the ticks, which is pretty much the same.

I don't know what era you are pining for. The original 6502 had many undocumented instructions. Most of them not very interesting, but certainly undocumented. http://nesdev.com/undocumented_opcodes.txt Here is a detailed examination of undocumented Z80 behavior. http://www.z80.info/zip/z80-documented.pdf The 8080 had undocumented instructions too. So now we are all the way back to pdp series. The pdp-8 had plenty of…

It’s not like these instruction were ‘secret instructions’ reserved for use by a secret cabal. They’re just leftovers from ‘don’t care’ parts of the microcode. I remember there’s quite a few that simply hang the processor because their microcode doesn’t include the ‘increase the program counter’ instruction so it turns into an infinite loop.

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#136

Post by _kbh_ »

moonchild wrote: post #27

The instruction in question looks to be encoded as 0f 0a. Which, sure enough, is missing from the official reference - https://files.catbox.moe/ktzqfg.png

the other appears to 0f 0e. at least if you go off this tweet. https://twitter.com/eigma/status/1373155650432290819 . 0f 0e is a 3DNow! instruction that AMD supported but not intel, which would explain why it has a mnemonic in Ghidra even though its undocumented for Intel processors.

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#137

Post by EE84M3i »

vlovich123 wrote: post #112
mjg59 wrote: post #109

Earlier quoted context omitted.

Windows can be booted into test keys mode, which allows the loading of unsigned drivers. We don't consider that a security issue because the privileges you need in order to switch to that mode are equivalent to the privileges you get by switching to that mode. It's the same here - the ME is the root of trust on Intel platforms. If you're in a position to execute arbitrary code on the ME then you've already got the ab…

I’m not saying that’s the case here, but that’s the general problem with the line of reasoning that “hey if you already have permission X then doing Y is the least of your concerns”. The concept of defense in depth literally relies on each barrier being independent and robust. That’s why you see hardening of Linux’s hibernate even though the common refrain is “well if you have physical access the game is lost”. There…

Where can I read about "hardening of Linux’s hibernate"? I'm curious

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#138

Post by mjg59 »

EE84M3i wrote: post #137
vlovich123 wrote: post #112

Earlier quoted context omitted.

I’m not saying that’s the case here, but that’s the general problem with the line of reasoning that “hey if you already have permission X then doing Y is the least of your concerns”. The concept of defense in depth literally relies on each barrier being independent and robust. That’s why you see hardening of Linux’s hibernate even though the common refrain is “well if you have physical access the game is lost”. There…

Where can I read about "hardening of Linux’s hibernate"? I'm curious

https://mjg59.dreamwidth.org/55845.html

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#139

Post by moonchild »

_kbh_ wrote: post #136
moonchild wrote: post #27

The instruction in question looks to be encoded as 0f 0a. Which, sure enough, is missing from the official reference - https://files.catbox.moe/ktzqfg.png

the other appears to 0f 0e. at least if you go off this tweet. https://twitter.com/eigma/status/1373155650432290819 . 0f 0e is a 3DNow! instruction that AMD supported but not intel, which would explain why it has a mnemonic in Ghidra even though its undocumented for Intel processors.

Interesting. Not sure how trustworthy that account is. The only 2-byte sequence documented by amd and not by intel that starts with 0f is, in fact, 0f 0e; that is FEMMS, which does match up with the length of the obscuring bar in the first reply.

And it does seem plausible that intel would pick proximal instructions for 'read' and 'write' of uarch state.

Re: Undocumented x86 instructions in Intel CPUs that can modify microcode

#140

Post by _kbh_ »

moonchild wrote: post #139
_kbh_ wrote: post #136

Earlier quoted context omitted.

the other appears to 0f 0e. at least if you go off this tweet. https://twitter.com/eigma/status/1373155650432290819 . 0f 0e is a 3DNow! instruction that AMD supported but not intel, which would explain why it has a mnemonic in Ghidra even though its undocumented for Intel processors.

Interesting. Not sure how trustworthy that account is. The only 2-byte sequence documented by amd and not by intel that starts with 0f is, in fact, 0f 0e; that is FEMMS, which does match up with the length of the obscuring bar in the first reply. And it does seem plausible that intel would pick proximal instructions for 'read' and 'write' of uarch state.

Only reason I consider it trust worthy is that it was retweeted by Mark Ermolov, which makes me think they got it right.
Post reply on HN