Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Posted Nov 15, 2023 18:01 UTC (Wed) by paulj (subscriber, #341)In reply to: Intel's "redundant prefix issue" by willy
Parent article: Intel's "redundant prefix issue"
Concurrency in OS kernels is also highly highly complex - "enterprise" Unix kernels for high-end server hardware should have been kept for Sun, SGI, etc. to develop.
Posted Nov 15, 2023 18:58 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (39 responses)
I must say that for having worked myself on a CPU 25+ years ago, and seen the cost of traversal of each layer, mux, latch etc, I've always been impressed by the ability CPU vendors have to hot-patch their signal paths like this without killing the overall performance too much, and I'm wondering how many percent extra frequency (and/or lower power usage) would be gained by totally removing this feature.
While I'm not particularly interested in decrypting the microcode files, I would appreciate it a lot if the issues fixed were openly explained and documented. I.e. the bug is caused by this bit being misinterpreted in exactly this condition, having this impact etc. For the fix we opted for this solution, it has this negative impact in this rare situation, thanks for watching. But we'll likely die before this happens...
Posted Nov 15, 2023 20:19 UTC (Wed)
by mfuzzey (subscriber, #57966)
[Link] (34 responses)
What is the justification for *encrypting* the microcode files though?
I can see the justification for *signing* them so that only official Intel updates can be applied by default (because if you are using an Intel processor you effectively trust Intel whereas you probably don't trust J Random Microcode Hacker). Though it would be nice to be able to add additional public keys for extra people / entities you *do* trust
Posted Nov 15, 2023 21:16 UTC (Wed)
by pizza (subscriber, #46)
[Link] (29 responses)
Security, actually.
If microcode updates can patch/work around vulnerabilities, they can also _add_ them.
This is also a good argument for _not_ publicly documenting the inner workings of the processors (or at least the inner workings that microcode can interact with)
Posted Nov 15, 2023 21:21 UTC (Wed)
by dullfire (guest, #111432)
[Link] (9 responses)
Posted Nov 15, 2023 21:54 UTC (Wed)
by jccleaver (guest, #127418)
[Link] (4 responses)
Security through obscurity works until it doesn't. But what a lot of idealists miss is that first part: It works.
Things that are less secure than they could/should be should be fixed, but that doesn't mean you have to make it easier for others to hack.
Posted Nov 15, 2023 22:39 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
That should be "security _only_ by obscurity"
> Things that are less secure than they could/should be should be fixed, but that doesn't mean you have to make it easier for others to hack.
Exactly. The more information you provide a would-be attacker, the easier job they'll have attacking you. Providing as little information as possible/necessary is always a good/sane tactic. Make them work for _everything_.
Posted Nov 16, 2023 12:30 UTC (Thu)
by yaap (subscriber, #71398)
[Link] (1 responses)
Common Criteria (CC) certification requires keeping the design confidential for example. Why? Because it forces an attacker into reverse engineering the particular device design, which is not impossible but definitely costly. And this will deter many attackers, all those who cannot justify the effort. In most cases security is not a binary proposition, it's an economic equation between cost of attack and cost of defense. And then obscurity makes perfect sense as a way to increase the cost of attack.
Everybody agrees "security by obscurity" is bad for algorithm and protocols. These are long lived, and we want the more review possibly to ensure strength and lasting protection.
But when it comes to a specific implementation, some amount of obscurity can be good, and can even be a requirement (see the CC spec)
For CC, I don't remember at which level it kicks in but for EAL4+ and above design secrecy is a requirement for sure, with requirements on how to control access and enforce this too. So you want to do an EAL4+ system? You must show your offices are properly secured for example, and that there are protection against tampering the design over the whole chain, from design to manufacturing to production. And most of this must be confidential, with proper access control.
So yes, I wish people would stop pushing "security through obscurity = bad" as if it were insightful. First, when it applies (algos & protocols) it is no longer insightful, everybody knows. And then there are plenty legitimate cases where it does NOT apply.
Posted Nov 16, 2023 16:17 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
When I did some stuff like this, the security I designed (they didn't use it) was pretty rudimentary. But the logic was very simple:
"This stuff has an economic life of about 6 months. If it takes them six months to reverse engineer what we've done, the results will be worthless".
Yes, of course I built in all the security I could, with every *obvious* hardening trick I could think of. But at the end of day, the stuff I was protecting wasn't worth throwing loads of money at.
Cheers,
Posted Nov 16, 2023 13:57 UTC (Thu)
by brunowolff (guest, #71160)
[Link]
Posted Nov 15, 2023 22:01 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
Okay. Please let me know the address of your residence, entry points, what security system protects them (eg locks, alarms, trigger mechanisms), and where you keep your valuables/secrets.
If you object to that, then you agree that security-by-obscurity has its place.
Posted Nov 15, 2023 22:55 UTC (Wed)
by Kamilion (guest, #42576)
[Link] (1 responses)
Posted Nov 15, 2023 23:30 UTC (Wed)
by halla (subscriber, #14185)
[Link]
I deleted a lot of things I wrote before I pressed the "preview comment" button, but...
Posted Nov 16, 2023 8:55 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link]
Posted Nov 15, 2023 21:55 UTC (Wed)
by mfuzzey (subscriber, #57966)
[Link] (6 responses)
People who want to experiment with microcode could then enable their own keys on their own system (at their own risk).
Posted Nov 16, 2023 9:43 UTC (Thu)
by Sesse (subscriber, #53779)
[Link] (5 responses)
Posted Nov 16, 2023 13:25 UTC (Thu)
by geert (subscriber, #98403)
[Link] (4 responses)
Posted Nov 17, 2023 0:13 UTC (Fri)
by p2mate (guest, #51563)
[Link] (2 responses)
Posted Nov 17, 2023 8:03 UTC (Fri)
by geert (subscriber, #98403)
[Link]
Posted Nov 17, 2023 8:17 UTC (Fri)
by Sesse (subscriber, #53779)
[Link]
Posted Nov 27, 2023 14:16 UTC (Mon)
by immibis (subscriber, #105511)
[Link]
Posted Nov 16, 2023 6:24 UTC (Thu)
by donald.buczek (subscriber, #112892)
[Link] (10 responses)
So what? I'm free to add bad kernel code, bad userspace code, enter `rm -rf /` or us a hammer on my cpu.
Agreed, people could be tricked to install bad microcode, e.g. by a false promise of performance gain, and brick their systems. But that only justifies a warning, not preventing people from installing whatever microcode they want.
Posted Nov 16, 2023 19:34 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
Posted Nov 17, 2023 9:17 UTC (Fri)
by james (subscriber, #1325)
[Link] (3 responses)
Posted Nov 17, 2023 16:55 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Nov 20, 2023 7:34 UTC (Mon)
by eduperez (guest, #11232)
[Link] (1 responses)
Posted Nov 20, 2023 19:11 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 17, 2023 12:05 UTC (Fri)
by paulj (subscriber, #341)
[Link] (4 responses)
Ergo, graphics drivers must be kept closed.
Posted Nov 17, 2023 16:56 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
I don't think so? All the modern display protocols (HDMI, DisplayPort) are digital.
Posted Nov 17, 2023 17:26 UTC (Fri)
by paulj (subscriber, #341)
[Link] (2 responses)
Regardless, the point is this argument "But the software could damage the hardware!" argument is not new. It was also valid in the 90s to 00s for graphics hardware. Had this argument been held as valid then, we couldn't have had open graphics drivers then.
It's just not a good argument.
Posted Nov 18, 2023 2:07 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
I hate to break this to you, but modern graphics cards _also_ rely on signed firmware. That's why NVidia cards had been so useless with open drivers until recently, the only allowed firmware was locked to the lowest power management setting.
Posted Nov 20, 2023 10:19 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Posted Nov 16, 2023 8:33 UTC (Thu)
by faramir (subscriber, #2327)
[Link]
Err, that's justification for signing the updates. Which can be done without encrypting them. Just saying...
Posted Nov 16, 2023 1:21 UTC (Thu)
by wahern (subscriber, #37304)
[Link]
Realistically I suspect the most pressing motivation is avoiding patent lawsuits. Microcode would reveal patentable aspects of the internal architecture of the CPU that would be more costly to discover and establish by other means. Patent holders are likely already suspicious, if not confidently aware, of potential infringements in Intel and AMD products, but to file an action you need some clear evidence, not assertions or hypotheses. Microcode could provide something solid for plaintiffs to stake their initial claims against, and
For the same reason vendors are often reluctant to release firmware source code, design documents, and other information that would make it easier to build patent and copyright infringement claims against their product implementations. Every industry is rife with actual infringement, and one of the reasons we haven't seen an IP apocalypse in the face of overly broad patent and copyright scope is because of the high cost of establishing a claim relative to the averaged expected value of any particular patent or copyright. IOW, you can't throw a patent portfolio at a defendant and see what sticks, confident that enough would stick to make for a net positive RoI; you always have to first identify and provide some solid evidence for specific patents or copyrights.
Obfuscation is illegitimate in the context of security, but highly valuable from a legal perspective.
Posted Nov 16, 2023 8:43 UTC (Thu)
by excors (subscriber, #95769)
[Link] (1 responses)
AMD copied Intel's microcode for their clones of the 287, 386 and 486:
> On September 2, 1993, AMD issued a press release disclosing for the first time that its "clean room" engineers had been given Intel's 386 microcode and that some portion of Intel's 386 microcode was probably incorporated into AMD's 486 microcode. The following day, AMD announced that it had intentionally exposed its engineers to Intel's 386 microcode in order to accelerate the development process and that approximately 25% or 600-700 lines of AMD's Am486 microcode were "substantially similar" to Intel's copyrighted 386 microcode.
Eventually (in 1994) it was decided that the copying was allowed under a 1976 cross-licensing agreement between Intel and AMD (https://www.latimes.com/archives/la-xpm-1994-03-11-fi-327...).
Intel appears to have supported microcode updates ("BIOS Update feature") since the Pentium Pro, originally developed around 1994, in which the microcode was encrypted:
> Each BIOS Update is tailored for a particular stepping of the Pentium Pro processor. The data within the update is encrypted by Intel and is designed such that it is rejected by any stepping of the processor other than its intended recipient. Thus, a given BIOS Update is associated with a particular family, model, and stepping of the processor as returned by the CPUID instruction. The encryption scheme also guards against tampering of the update data and provides a means for determining the authenticity of any given BIOS update.
Given the uncertain legal situation at the time, it seems quite plausible that Intel decided to encrypt the microcode largely to stop AMD copying it again. Maybe modern CPUs are so much more complex that there's no hope of copying anything useful nowadays, but inertia is very powerful and it's probably hard for some well-meaning Intel employee to successfully convince enough people that the remaining arguments for encryption are not compelling enough and that they could safely stop encrypting it now, so instead they've continued.
Posted Nov 16, 2023 10:02 UTC (Thu)
by james (subscriber, #1325)
[Link]
They replied "Well, what we've already done is put a bunch of Linux boxes in the lab and
they work just fine." We then decided to take the Linux boxes on an “extended field trial” for
the next few months and if it works well, we'll tell Albert that we did it.
And this is the Dilbert moment at the end of all this. The Linux experiment worked
beautifully. We got all the cycles we wanted, and it was as stable as a rock. We got our
validation back on track. At the end of the project, the guys who did that guerilla action, they
got an IAA award, the highest Intel technical award, from Albert for having taking (sic.) the
initiative.
Posted Nov 16, 2023 10:15 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Turn that around and tell the same about, e.g., internals of a compilers. They are even doing the exact same things: convert something human wrote into something hardware understands. Two most important ones are gcc and llvm. How easy it is to change the plugins for these two without looking on the source, just from documentation? How easy is it to fix bugs in these compilers by just altering plugins, without touching the source? Internally there are people who work on microcode have access to schematics of the CPU so their work is similar to working on these plugins with the source code for gcc/llvm available, not with trying to deal with just plugins. Just like gcc/llvm plugins reveal a lot of information about how compilers themselves work microcode reveals a lot of info about hidden properties of AMD/Intel CPUs. Not only these can be picked up by ARM or Qualcomm guys, more importantly, these may be picked up by Chinese companies which is something US tries to avoid. If you want to see what and how can be revealed from microcode dump I recommend you to look on Ken Shirriff blog. Note that “bug”, very similar to what we discussing here, was discovered in 8086 CPU (use of This shows that in case of CPUs you can fool some of the people all of the time, and all of the people some of the time, but you can not fool all of the people all of the time becomes you can hide information with encrypted microcode from everyone for a few years… enough for the CPU to become obsolete.
Posted Nov 15, 2023 21:23 UTC (Wed)
by pizza (subscriber, #46)
[Link]
I was once told that the most power hungry part of a certain MCU design was the block of comparators used to provide low-level patch entry points.
Posted Nov 15, 2023 21:32 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
Exactly this. The designs (and implementations) are _extremely_ complex. (though these days it's tens of billions of transistors, with more potential states than there are atoms in our universe)
> it becomes virtually impossible to even document it at all, let alone try to explain how the microcode patches work!
It's not that it's impossible to "document", but effectively impossible to simply _enumerate_ all potential states that might matter, much less _test_ that they work as intended.
Now as far as the microcode itself is concerned, I'd expect it's pretty straightforward to document _how_ the mechanism works in general, but for that to be useful you'd have to effectively expose the entire inner register/API/etc of the processor. And Intel is understandably reluctant to publish those trade secrets.
Posted Nov 16, 2023 4:43 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link]
That's what I meant, "impossible to document" implies "without providing the full internal schematics". Of course, in a 10000-page schematics of the whole stuff there certainly are references to bitXXX coming from the patch system. But it's quite different to place bitXXX on the control pin of a mux on a diagram than to document what bitXXX does. I wouldn't be surprised if the doc for the microcode update stuff only enumerates ranges of bits and the associated blocks and pages in the schematics, and that one has to actually search for them directly in the schematics, otherwise the doc would always be outdated or never finished. And that's not counting the risks of errors in that doc itself which can have devastating effects.
Posted Nov 16, 2023 17:27 UTC (Thu)
by cry_regarder (subscriber, #50545)
[Link]
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Wol
Intel's "redundant prefix issue"
By hiding how the system works, you forgo reviews that might find and/or fix issues. Whether or not that trade off is good is going to depend on the situation.
The other issue is that there can be multiple parties involved, whose threat models aren't aligned. While a sellar of a product might not want their competitors to be able to reproduce their product, buyers aren't going to care about that, but might have limited trust in the sellar and may want to be able to verify that the sellar isn't compromising their security. The sellar might also want to retain some control over the product after sale, while buyers will generally want full control of what they buy.
Sellars also care about making sales, so if buyers aren't buying their product because of obfusication, they need to balance that against how they benefit from obfusication.
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Unfortunately it's proprietary.
http://www.apollo-core.com/index.htm?page=coding&tl=1
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
How is this different from overclocking?
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
> Had this argument been held as valid then, we couldn't have had open graphics drivers then.
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
I would be surprised if unencrypted or leaked microcode hasn't figured prominently in some costly patent lawsuits in this industry.
Intel's "redundant prefix issue"
(https://www.sec.gov/files/litigation/admin/3437730.txt)
(http://datasheets.chipdb.org/Intel/x86/Pentium%20Pro/PPPB...)
Intel's "redundant prefix issue"
Intel appears to have supported microcode updates ("BIOS Update feature") since the Pentium Pro, originally developed around 1994, in which the microcode was encrypted
Bob Colwell, one of the lead developers of the Pentium Pro, explained:
In fact, remember the micro code patch facility, I had
a lot of fights over that of that exact nature because the executive VPs would say, "You want
me to allocate chip real estate on a facility to make up for the mistakes that you think you
will have made? Why do you not just make no mistakes and then we don't have to deal with
them on the chip". And I said "If you can find somebody who can actually deliver you perfect
designs of any sort, you really should hire them and if they can do it, you should fire me and
put them in my place, but I don't know how to do it, so until such day as you show me the
magic..."
and
The way P6 worked was that it would take the x86 instruction, turn it in to
micro-ops, and the instruction hasn't finished until the last micro-op associated with that
instruction has finished. So as a microcode writer I might know that to implement that
instruction took me five micro-ops and here they are, but I don't want those outside of Intel
to know that, that's microcode, some of Intel’s family jewels. If you tell people the
microcode of your machine they can design their own machine much more easily. There's a
significant IP aspect of the microcode, so we had to try to find a happy balance between
enough information to let the performance analyst succeed and not so much that we would
expose intellectual property in our microcode. The compromise that I proposed was that if
it's four micro-ops or less [VTUNE would] show them the actual sequence, because for instructions that
simple, there's no mystery to what it does anyhow. But for instructions like far call through a
gate there's some really complicated x86 stuff; there might be 200 micro-ops. We don't show
you those micro-ops; instead, we say the x86 instruction takes 200 micro-ops.
He then went on, in answer to the very next question, to say:
I said if you find a bug in UNIX for example and it's messing you up
go find out where it is. Go into the source code, figure it out, work around it, don't let it stop
you.
and, when Intel had transitioned from commercial UNIX to Windows NT:
Suddenly NT comes along, and we don't have source code. We're not
allowed to have source code. We're not even allowed to cheat and look at the assembly
code, we can't disassemble it.
and
Next the validation chief came to me saying "I'm
worried. We're not getting the cycles that we used to get. We used to crank through a certain
number of validation cycles every night and now we have more machines with theoretically
higher capacity and I'm getting far less useful output. So why is that? Is it that they're slow,
not as efficient? Half the jobs I submit, literally half, never finish. They never succeed." I said
"Is it a random thing?" He says "yeah as far as I know, I have no idea what the pattern is, I just
know that every hundred jobs I submit, I get fifty back. And so it’s going to take me twice as
many machines, for twice as long.
and
...the validation crew said "we're not going to finish the
project this way. So we're going to take drastic action. How about we get a bunch of Linux
boxes in here and we start using those." And so I mentioned that to Albert who was the
decision maker here and he said, "No, over my dead body. I do not want that, you can't have
that. You have got to make this Windows NT conversion; NT is the future." So I came back to
the validation crew and I told them what he said.
> If the world is relying on hardware that is not and cannot be documented we have serious problems...
Intel's "redundant prefix issue"
rep prefix with mul negates the result) in said microcode almost immediately after is was decoded yet it eluded hackers of last century for decades!Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"
Intel's "redundant prefix issue"