The Spectre and Meltdown exploits bring up a few things that are extremely surprising to me. Flabbergastingly* surprising. What about you?
That their microcode is in flash and not ROM.
That you can change it with software instead of requiring connection to a programming device.
That their microcode, which should be very hardware specific, has so much code in common that every CPU model has the same vulnerabilities.
x86 is a fabulously complex and klugey architecture. It needs gobs of microcode, so will have lots of bugs - all code has bugs - so needs flash. The Pentium didn't have microcode in flash, and had the notorious fp divide bug, which cost Intel hundreds of millions, so new parts are flash.
They probably cache the microcode for speed.
x86 is ancient garbage. RISC was invented partly to get away from slow, complex microcode.
I don't know how ARM and such do floating point. It boggles my small brain to imagine doing fp without microcode.
We are still living in the dark ages of computing.
It's been that way since the Pentium II circa late 1990s
Two separate issues.
That the vulnerability dates back to 486s, and shows up in dozens of unrelated architectures, speaks more to a fundamental quirk of the design concepts, methods and processes in cache systems.
It certainly wasn't a problem back in the 90s. The exfiltration rate might've been bits/second. No need for such tiresome methods when Java was alive and well, just as vulnerable and naive as everything else, back then.
Has the problem just gone unrecognized all this time? Was it recognized, but ignored -- rightly, at the time, for being too obscure and useless? Has it not been reconsidered since then? Entirely plausible.
Presumably, the same phenomenon can be found in many cache systems, of any type. How about timing access to web pages on a server (which are cached), to determine the traffic pattern of the site? (It would have to be done slowly, because the statistics of network latency introduces a lot of error that masks the underlying signal.)
As for updatable microcode, that's been tried from time to time, AFAIK. I suppose the vulnerabilities are (should be) the same as any software update mechanism: are the update instructions locked to the supervisor, or better yet, hypervisor? Are the drivers signed? Are the keys long enough, encrypted with generally-considered-secure crypto? (And, mind all the turtles beneath this. Like Intel's notorious problems with securing said hypervisor.)
Tim
No surprise there; the famous Pentium divide bug was 'repaired' by field-replacement of the chips, and Intel doesn't want a repeat of that. At a hardware level, flash IS ROM, not really more costly.
It saves pin count, maybe? My crystal ball is murky, try again later.
Reusable code, including microcode, makes sense, but it's odd that there have never been field-upgrades available in the past, only now do we find that there is capability to do such. Was this a trade secrecy ploy? Did some dice get new part numbers from Intel when the same hardware was programmed for different behaviors?
Not every model has the same code, because the 'patch' doesn't cover all models, there are useful CPUs which seem to be abandoned.
Modern processors do not execute the x86 code directly, but translates it to some instructions suitable for the actual hardware architecture. This can be done in real time as the first stage of the instruction pipeline or it can be done once on demand and then translated code is stored into RAM for further executions. Examples of the latter method are the Transmeta processor as well as the FX!32 environment which allows Windows NT x86 code to be executed at full speed on the DEC Alpha RISC processor.
The original reason for designing compact CISC instruction set was the small size, high cost and slow speed of core memory. It was essential to keep the applications as small as possible. The microcode could be placed in a small, but fast microcode memory.
When main memory prices dropped drastically and speed increased significantly, it become possible to control individual points within the processor with dedicated bits in the long application instruction word. This eliminated the need for microcode in some RISC processors.
There is nothing special of doing floating point in hardware, but for efficiency, needs a _long_ pipeline and lots of hardware. In a general purpose processors, it is hard to generate new operands to keep the pipeline occupied. Thus, the cost becomes so high that the price is not justified.
On a SIMD vector processor, there will always be new operands available to keep the pipeline occupied, justifying the pipeline cost.
We are still using Pascal p-code or Java bytecode. This just a new form of CISC :-).
Il giorno sabato 28 aprile 2018 20:57:36 UTC+2, whit3rd ha scritto:
there were, and they did. Usually microcode is updated during BIOS update so you don't see it.
Bye Jack
Why would you think they'd do it differently? If you put it in ROM, it'd mean the microcode would have to be completely done before they could integrate a test.
I would hope so. The "vulnerabilities" are inherent in the way the architecture works.
There ya go.
x86 has code that will run on it. ARM does too, but not as much.
It's fine. I haven't exactly hit the limits of it but SFAIK, it's still IEEE 754.
I worked for Star Technologies who made array processors which were a float ing point chip in a double wide rack cabinet for minicomputers. It was not microcoded in the sense of having instructions which were then run on micr ocode. It was programmed directly in what would really be the equivalent o f microcode, >100 bit wide instructions, one part for the ALUs and another for the memory interface. Being a pipelined machine with four ALUs and a single 8 way interleaved memory interface it was no cake walk to program. I believe part of the business was helping the customer get their programs running. Mostly oil exploration acoustic reflection stuff.
Lol!
Rick C.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required