back to article Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign

A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug. Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes …

Silver badge
Unhappy

Hmmm...

I hope the kernel patches are intelligent enough to ONLY apply the 'slowness feature' when absolutely necessary, and not simply slow EVERYONE down to be "fair" (or, on the part of devs, LAZY).

40
21
Silver badge

Re: Hmmm...

Who knows. With Linux of course we can tell. With Windows, possibly benchmarks are our friend if MS are keeping stum about the matter.

From a security point of view it would be better to leave things as they are if the hardware is not effected; better to be running mature code than to be running what seems like a major update out together in a bug hurry.

38
3
Silver badge

Re: Hmmm...

Its going to have to slow everything down - if the OS doesnt do the checks on everything then its leaky as a sieve.

Someone just took £50 from my cpu!

56
2
(Written by Reg staff) Silver badge

Re: Hmmm...

The KPTI Linux patches are applied to all Intel x86 CPUs. AMD submitted a patch to stop it being automatically enabled on its chips. It is possible to turn off KPTI during boot up.

C.

71
0
Silver badge

Re: Hmmm...

Would this mean distributing Intel & AMD specific binaries, or would users have to compile their own kernel to enable/disable the patch as necessary?

6
5
Bronze badge

Re: Hmmm...

If written intelligently, the kernel would detect the CPUID and supported instruction sets, and apply itself appropriately.

Ideally the kernel would flag all Intel chips, and once Intel fixes their problem, Intel releases a new feature flag that indicates a fix to the problem that the kernel could also flag off of.

42
1
Cl9

Re: Hmmm...

Kernel memory is mapped to user mode processes to allow syscalls (a request to access hardware/kernel services) to execute without having to switching to another virtual address space. Each process runs in its own virtual address space, and it's quite expensive to switch between them, as it involves flushing the CPU's Translation Lookaside Buffer (TLB, used for quickly finding the physical location of virtual memory addresses) and a few other things.

This means that, with every single syscall, the CPU will need to switch virtual memory contexts, flushing that TLB and taking a relatively long about of time. Access to memory pages which aren't cached in the TLB takes roughly 200 CPU cycles or so, access to a cached entry usually takes less than a single cycle.

So different tasks will suffer to different extents. If the process does much of the work itself, without requiring much from the kernel, then it wont suffer a performance hit. But if it uses lots of syscalls, and do lots of uncached memory operations, then it's going to take a much larger hit.

That's what I make of it from understanding of it, which might not be 100% correct.

57
1
Silver badge

Re: Hmmm...

What do you think?

0
5

This post has been deleted by its author

Silver badge

Re: Hmmm...

"So different tasks will suffer to different extents." But the hardware...?

"The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware."

So now we'll have a little tax charged for every interrupt - *every* *interrupt*. How much software do you run that doesn't use disk or network or any I/O?

This was not the financial micro-transaction future I was thinking of.

35
0
Silver badge
Devil

Re: Hmmm...

Someone just took £50 from my cpu!

Suddenly your CPU is like Bitcoin.

Or the EURO

17
8
Silver badge

Re: Hmmm...

So we all get new CPUs on Intel like we did with the Pentium floating point bug?

41
0
Silver badge
Mushroom

Intel Inside...

Can run but can't hide.

What a clusterfsck.

Yet another reason to stick to AMD.

58
6

Re: Hmmm...

There is precedent here. The kernel still tests for the F00F bug on boot and applies the kernel-level work around only on systems that need it. Thus the slow down is only applied where it is needed. I expect this will happen in this case, although we are talking about a significant architectural change here.

15
0
Bronze badge

Re: Hmmm...

Will this slowdown affect iPhones? /sarc

20
15
Silver badge

Re: Hmmm...

So this puts us more or less to where a true microkernel would be in terms of performance? Virtually a full context switch cost for any trip into the kernel?

A breathtaking error if I've understood it. In a fair market this should kick the door down for AMD.

47
3
Silver badge

Re: Intel Inside...

Hmm, good timing... I bought a new PC just before Christmas and decided to go AMD after about a decade of Intel...

45
1
Anonymous Coward

Re: Hmmm...

Only a tiny few are affected, but since you're a good friend, here's a $29 battery replacement deal to shut you up.

23
0
Silver badge

Re: Hmmm...

I think we need to return to PDP11, where you had an alternative set of memory management registers for program and supervisor (kernel) mode. When you issued the instruction to trigger the syscall, the processor switched the mode, triggering an automatic switch to the priv. mode registers, mapping the kernel to execute the syscall code..

This meant that it was not necessary to have part of the kernel mapped into every process.

IIRC, s370/XA and Motorola 68000 with MMU also had a similar feature. I do not know about the other UNIX reference platforms like VAX (the BSD 3.X & 4.X development platform) or WE320XX (AT&T's processor family used in the 3B family of systems - the primary UNIX development platform for AT&T UNIX for many years), but I would suspect that they had it as well.

I first came across the need to have at least one kernel page mapped into user processes on IBM Power processors back in AIX 3.1, where page 0 was reserved for this purpose. In early releases, it was possible to read the contents of page 0, but sometime around AIX 3.2.5, the page became unreadable (and actually triggered a segmentation violation if you tried to access it).

38
4

Re: Hmmm...

And a soldering iron for all the cpu’s that are welded to the mobo...

8
0
Anonymous Coward

Re: Hmmm...

Those processors (nice though they were) didn't do speculative execution.

13
1
Silver badge

Re: Hmmm... @AC

That's true. Having a address space change would have to disable speculative execution, because it would also have to try to predict which address space it would be in.

Actually, thinking about it, it still has to, because if the mapped page is protected from view, there still needs to be some mechanism to lift the protection to allow the speculative execution of the branch of code, before the decision is taken. But in theory, the results of the branch-not-taken should be discarded as soon as the decision is made, so that the information gathered could not be used. Maybe there is something in the combination of speculative execution and instruction re-ordering (not mentioned yet) which allows data to be extracted from later in the pipeline.

Maybe this is the problem, and if it is, it's probably a design flaw rather than a bug, Interesting.

13
0
Silver badge

Re: Hmmm...

I think we need to return to PDP11

While the elegance of the PDP-11 design is beyond dispute, it wouldn't scale to the performance of current systems. Notably, its memory management was very simple: 8 base and length registers for each execution mode. As soon as you go much beyond a 64k address space it becomes infeasible to have a full set of mapping registers on the CPU and you're forced down the TLB road.

What might well make sense is if it were possible to run the (key parts of the) kernel in a "protected real" mode (i.e. with no virtual address translation at all, but with some form of memory protection using keys or limit registers. If you don't have enough physical memory to contain a kernel, you're not going to make much progress anyway. And it's only one of many areas in which improving performance with caching of one kind or another leads to potential anomalies with specific execution patterns.

Not that any speculation (sorry!) of that kind helps with the current debacle - but it does illustrate how the growing complexity and unauditably of processor designs has largely been overlooked until recently while we've been principally worried about software security.

16
0
Silver badge

What if ?

Class action lawsuit -> recall -> Intel chapter 11

29
1
Anonymous Coward

Re: Hmmm...

Ideally, any I/O heavy software will use large buffers and avoid calls like fgetc, instead asking the kernel to read in a large chunk at a time to its buffer with something like fread, thus reducing the number of system calls being made.

4
0
Silver badge

Re: Hmmm...

The problem with the PDP11 method is the kernel code has to do fiddly read-userland-from-kernal operations to get the call's parameters and data. If the kernal is paged in and running in kernel memory at &o004010 and the caller has its parameters in userland at &o004010 the kernal can't read them by just reading from &o004010 as that would read kernel memory, it has to use MoveFromPreviousInstructionspace (MFPI) instructions to copy the parameters to local (kernel) space, and MoveToPreviousInstructionspace (MTPI) instructions to copy stuff back to userland, such as loaded data.

9
0

Re: Hmmm... @AC Might not even leak data

The leak may not even be data, it could be as small as a timing change from the spec-ex path taking longer to fault, or not, allowing the attacker to probe the kernel space for not/valid pages - so defeating to an extent the kernel memory-map randomisation? Worse might be a spec-ex branch on spec-read secret data which affects timing similarly, without directly exposing the data itself.

5
0
Trollface

Re: Hmmm...

> In a fair market this should kick the door down for AMD.

What's the betting intel are pushing M$ to enable the KPTI patch for all chips regardless of mfr to try and shore up relative losses in performance?

38
0
Silver badge

Re: Hmmm...

@Gathercole

Back in the 1970s I was asked to make a PDP11 system go faster. It was running DEC's real time OS, viz RSX11. The critical part of the program needed to make a lot of OS calls. I arranged for that region of the program to be mapped into kernel space (using a 'connect to interrupt' facility) and got my speedup. The cost was a section of high-risk code.

There is a reason why interrupts used to return control to the kernel. It may be that a disk transfer has finished, thus allowing some more important program to resume. In more general terms, the context has changed and the system should adjust, particularly if several programs are running. The PDP11 could respond to interrupts within microseconds, perhaps to capture volatile data from fleeting registers on special hardware; but it could be a long time returning to the point of interrupt.

9
0
Silver badge

Re: Hmmm... @J.G.Harston

That is true, but for volume data moves was mitigated by DMA from disk directly into memory-mapped buffers in the process address space, using the UNIBUS address mapping registers, which allowed raw DMA transfers to addresses outside of the kernel address space.

Of course, not all PDP11 models had the UNIBUS (or, I presume a similar QBUS) feature, but pretty much everything after an 11/34 would have. I had an unusual 11/34e that also had 22-bit addressing, which made it much more useful.

8
0
Silver badge

Re: Hmmm... @Primus Secundus Tertius

The reason why PDP-11 could respond so quickly to interrupts was this facility to switch address spaces without having to save the register context. On other architectures, in order to take an interrupt, the first thing that you need to do is save at least some of the address registers, and then restore them after you've handled the interrupt.

IIRC, the PDP-11 not only had duplicate address mapping registers, but also had a duplicate set of some of the GP registers, so you had to do pretty much nothing to preserve the process context that's just been interrupted. This is what made the interrupt handling very fast.

The time to return from the interrupt was entirely down to the path length of the code handling the interrupt. The actual return mechanism was as quick as the calling mechanism. There were unofficial guidelines about how long your interrupt code should take, which I believe were conditioned by the tick length for the OS. If you took too long, you would miss a clock-tick, which would result in the system clock running slow.

In addition, I also believe that there were a small number of zero page vectors that were left unused by either UNIX or RSX11/m (the version of RSX I was most familiar with) that allowed you to add your own interrupt handlers for certain events.

9
0
Gold badge

Re: Hmmm...

Pretty sure the FPU bug was easily patched, they just added one or two NOOPs between certain instructions. It was a compiler fix.

1
0

Re: Intel Inside...

Me too! Ryzen Ryzen, La la la!

10
1
Roo
Silver badge
Windows

Re: Hmmm...

"I think we need to return to PDP11, where you had an alternative set of memory management registers for program and supervisor (kernel) mode."

There are already plenty of non x86 derivatives out there that don't have this bug, all that's required is folks to make the move. :)

Would be nice if vendors updated their benchmark results in the light of a 30% performance hit, so we can get an apples-apples comparison against processors that don't suffer from this particular fault.

13
0

Re: Intel Inside...

"Hmm, good timing... I bought a new PC just before Christmas and decided to go AMD after about a decade of Intel..."

Good call. I just bought a new laptop myself and went with AMD as well. It's going to be some time before updated chips from Intel come out as this is a hardware problem with speculative instruction execution on the pipeline. Hardware means that Intel will have to redo all the masks that are used for the fabrication process.

12
0

Re: Hmmm... @AC

"the results of the branch-not-taken should be discarded"

From the and hint the problem isn't speculative execution as such, it's fetch hardware that reads memory before checking permission, presumably changing cache state irreversibly. It speculative execution disables the privilege violation because the code path is discarded there's no way to detect the event or take any remedial action like invalidating the tlb. However invalidating the tlb would leak address layout information anyway!

The correct thing is blocking the fetch ops completely while still potentially raising an exception if that part is taken. Better, raise an exception anyway. Which appears to be the amd approach. Intel look like they saved some transistors and maybe gained a tiny speed advantage without thinking it through.

11
0
Silver badge
Unhappy

Re: Intel Inside...

" I bought a new PC just before Christmas and decided to go AMD after about a decade of Intel"

Just starting to think about a laptop replacement. Looked at PC Specialist. Not an AMD in sight.

3
0

Re: Hmmm...

did you mean, eh, crippling AMD ??

you bet, it will happen

how come that AMD would be faster ? impossible !!!!11!!1!!!

6
0
Silver badge

Re: Hmmm...

There are already plenty of non x86 derivatives out there that don't have this bug, all that's required is for vendors to make them as readily available so as to enable folks to make the move. :)

10
1

Re: Hmmm...

The other issue here is what MS does regarding Windows 7. It would not surprise me in the least if they tried a clever/efficient patch for Windows 10 and a simpler (and slower) bodge-job for Windows 7/8. Still, I guess we'll find out soon enough. They'd also better make sure that the changes only apply to Intel machines. I don't want MS to arbitrarily slow down my AMD PC as a result of this - you'll note that AMD submitted a Linux patch to ensure their CPUs weren't caught up in this, will MS do the same?

20
1
Anonymous Coward

Re: Hmmm...

"What might well make sense is if it were possible to run the (key parts of the) kernel in a "protected real" mode"

If the kernal is in the same address space as user code and using the same pipe then nothing changes. Either a seperate CPU/cache for kernal code and without speculative execution or scrap the whole model.

Basically no kernal code should be run before security has been validated and that means stalls in kernal code execution.

3
1

Re: Hmmm...

"did you mean, eh, crippling AMD ?? you bet, it will happen how come that AMD would be faster ? impossible !!!!11!!1!!!"

If that happens, I can safely guarantee that AMD will not be quiet about it. Lawsuit anyone?

19
0
Silver badge

Re: Hmmm... @Roo

I think that you should say were plenty of non-x86 processors out there. There really aren't any more, with just AMD (which is an x86 derivative, but may not be affected), Power, zSeries, ARM, and the tail end of SPARC, and I suppose Itanium (just) being around.

You could also say, I suppose, that there is a MIPS processor around still, but you'd have to buy it from the Chinese.

A lot of other architectures never made the switch to 64 bit (although Alpha was always 64 bit). Architectures we've lost include Alpha, PA-RISC, VAX, all Mainframe apart from zSeries, DG Eclipse, Motorola 68000 and 88000, Nat. Semi. 32XXX, Western Electric 32XXX, various Honeywell, Burroughs and Prime systems, and various Japanese processors from NEC, Hitachi and Fujitsu.

This is largely the cost of wanting cheap, commoditized hardware. You end up with one dominant supplier, and suffer if they get something (or even a lot of things) wrong.

13
0

Re: Hmmm... @AC Might not even leak data

Now that would be embarrassing to the Rust evangelists, who think their one trick pony solves every possible security issue! They'll suppress that idea with their usual fervor I bet. To me it's the height of vanity to think you can pre-define and therefore pre-solve every possible side channel and backdoor attack. The endless game of thief vs locksmith is...endless...

0
3

Re: Hmmm...

"If the kernal is in the same address space as user code and using the same pipe then nothing changes. Either a seperate CPU/cache for kernal code and without speculative execution or scrap the whole model.\"

Even in user space page permissions exist. There's nothing intrinsic to a flat, shared address space that stops a CPU enforcing all permissions at the thread/page/exe page level, all the way down to prefetch and cache access. Separate cache/memory systems per ring is a high price to pay to replace access control logic in the memory system. Dumping cache state is an even higher price to pay for not having that logic.

2
0

Re: Hmmm...

By the sound of things it looks like the bug allows users (non-admin) to see the guts of the OS. This means, that once published, hackers will be given details as to how to take over the computer if you haven't upgraded (security risk).

What is naturally to fear is that the first generation code (patch) will be to block these details. New, ad-hoc code means there may be stability issues (return of the blue screen ??). If the OS developers run all their security test vectors, no old holes should open up. The question I think you have is will there be some new hole, I'm not sure anyone can know for sure - we can only demand that old bugs don't return.

What we can expect is for code to run slower. If I interpret the description well, the more threads you have the slower the code should run, ie it should impact JAVA code (scripts/interpreted code) more than C++(compiled code). It'll expose individual coding styles and change coders tactics for performance optimization.

4
1
Anonymous Coward

Re: Hmmm...

" With Linux of course we can tell. With Windows, possibly benchmarks are our friend "

But Windows has far more in depth performance diagnostic features off the shelf than Linux does?

2
7
Roo
Silver badge
Windows

Re: Hmmm... @Roo

"I think that you should say were plenty of non-x86 processors out there."

There are still plenty out there, not all of them will be a viable alternative for your application...

"There really aren't any more, with just AMD (which is an x86 derivative, but may not be affected),"

In my view AMD share the same problem as Intel: The x86 ISA (64bits, extensions, warts and all) are simply too complex to test properly. It's a scalability limit in the design space - and this isn't a new problem - it goes back decades. We are seeing bugs span multiple steppings AND generations of product line as a matter of routine. The x86 vendors are physically unable to sell us a fully functional chip even if we pay top dollar for it.

As I see it, as customers, we have no alternative but to go to other ISAs over the long run - simply to get a working chip without the "feature-itis" imposed by 30+ years worth of workarounds.

3
2

Re: Hmmm...

I suspect the class-action lawyers are already sharpening their knives depending on the performance hit.

8
0
Silver badge
Happy

Re: Hmmm... @Peter Gathercole

I think we need to return to PDP11, where you had ...

The only reason I would need is,well,PDP11.. nuff said.

2
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2018