Earlier quoted context omitted.
Don't use CPUs from companies that have employees that can be kidnapped.
Doesn't seem like that would leave many possibilities... ;)
I guess out of business CPU companies are one easily accessible category.
Undocumented x86 instructions in Intel CPUs that can modify microcode
91–100 of 145 posts
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#92Earlier quoted context omitted.
In most cases there is a public API which is documented and a private API which is not. In this specific case, users do not have the ability to use this instruction, so there is no reason to document it.
Why is it acceptable for companies to keep such information away from a consumer?
Because it is not part of the public-accessible product and the company is free to change it at will from one version of the product to the other, or even between multiple batch of the same version.
You see it from an "they should inform us" POV, but there is also the "there is no guarantee it will be there" side.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#93Is there a way to use this for consumer good?
1. Like unofficially turning on ECC support on non-ECC chips assuming the hardware allows for it?
2. Or increasing total supported RAM size on lower end chips?
3. Unofficial open-source microcode updates(performance/security) for older unsupported chips?
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#94Earlier quoted context omitted.
Why would they do that?
I can't imagine why someone would hide details of the product they are selling. That is dishonest and should be illegal. Imagine if someone was selling food and would omit some ingredients from the list or you buy a house with a basement and you don't get a key nor info what's inside.
Does all the software you buy disclose all its functionality?
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#95Earlier quoted context omitted.
Can you give an example of a processor whose microcode was publicly documented? (Barely-public documents like patent filings don't count.)
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.
That’s .001% of information that describes a processor. Anyway people measure it and provide it today too.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#96Earlier quoted context omitted.
> 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…
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.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#97Earlier 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.
That’s .001% of information that describes a processor. Anyway people measure it and provide it today too.
What is the other 99.999% of information? Yes, there was some undefined behavior that was not in the official manuals but certainly not a 100000 times what was in there.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#98Earlier quoted context omitted.
Why is it acceptable for companies to keep such information away from a consumer?
Because it is not part of the public-accessible product and the company is free to change it at will from one version of the product to the other, or even between multiple batch of the same version. You see it from an "they should inform us" POV, but there is also the "there is no guarantee it will be there" side.
What do you mean it's not publically accessible? A bank's vault is not publically accessible because there is a meter of steel, concrete, and armed guards.
We can debate if some private bank API's are publically accessible (you can still DDOS them). This shit, however, is inside my property, that I bought with my money, and it might end up being used by some malware. It is by definition accessible, and could be a security bomb.
How can any believer in free market defend companies secretly selling to comsumers the equivalent of a dangerous remote control mechanism embedded in their car?
Market only works if sellers aren't lying all the time, and in IT industry we made it the norm.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#99Earlier quoted context omitted.
Plot twist: there’s been a few ME vulnerabilities. And who knows what other purposeful ME backdoors there may or may not be.
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.
Yeah, like a rootkit on the cpu.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#100Earlier quoted context omitted.
The problem with microcode is that it’s specifically tailored to each specific microarchitecture. The microcode for, say, Skylake, won’t work on Haswell. And it definitely won’t work on any AMD CPU. Intel and AMD almost certainly have compilers/assemblers of sorts that handles turning the microcode assembly-of-sorts into the correct bits, but they’re not portable.
I'd settle for a single specific microarchitecture, just to see what was possible.
Oh for sure. Even if it’s the P6’s microcode (the first with updatable code), I’d take it. I’ve always wondered what microcode looks like in these processors, and how it functions. There is “p6tools”[0][1] which looks interesting. But if Intel released info on it, that’d be really cool.
Sidenote: Ken Shirriff has reverse engineered the ARM1’s microcode,[2] but it’s a “horizontal” microcode (bits control CPU blocks directly) while x86 uses “vertical” (RISC-like) microcode.
[0]: https://github.com/peterbjornx/p6tools
[1]: https://www.youtube.com/watch?v=4oFOpDflJMA (slides: https://hardwear.io/netherlands-2020/presentation/under-the-...)
[2]: http://www.righto.com/2016/02/reverse-engineering-arm1-proce...