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 …
"I've been using AMD cpu's since the K series in the late 90's **** I feel old now
Smug but old :)"
I know what you mean. I've been using solely AMD since my 486 DX/2 66MHz CPU.
What can I say, I like supporting the underdog.
>I've been using AMD cpu's since the K series in the late 90's
As you're a long-time AMD fan, would you satisfy my curiosity? Was the increase in your electric bill through the use of Bulldozer-class CPUs offset by the ability to supplement your furnace with your computer during the winter?
In my case yes. seriously My room was consistently 10 degrees warmer then the rest of the house. Toss in a descent video card and I had to use monster after market cpu cooler or the damn CPU would over heat and shut down.
Just wondering, what are the chances that the Linux fix is the best possible? Perhaps Apple and/or Microsoft will come up with a faster solution, perhaps a better general solution which could be applied to Linux as well. Or, perhaps OS-specific fixes taking advantage of characteristics of Mach or Windows that Linux doesn't happen to have. (Not a slam on Linux, just noting that the OSes have different architectures and features that could conceivably come into play in designing a fix.)
There's a reason AMD didn't follow Intel down this hole. They've known about it for nearly 20 years and Intel did too and chose to implement anyway. Find an old copy of VMS Internals and Data structures. If VMS couldn't keep you out, it killed itself to limit the damage. "Page Fault IPL too High". Intel got the engineers but AMD got the IP when the lab/fabs were sold off. Evidently, AMD paid attention.
Intel got the engineers but AMD got the IP when the lab/fabs were sold off. Evidently, AMD paid attention.
The DEC engineers that ended up at Intel were, for a large part, from the software side of things; the compiler group went over almost lock, stock and barrel. AMD got a number of Silicon Wranglers who had been working on AXP and chipsets; several AMD processor subsystems bear a strong resemblance to their AXP counterparts.
More than you know... I believe, without knowing, that early AMD64 and Alpha processors were designed to be pin compatible. Certainly if you looked at the motherboard for early AMD64 you would see an Alpha southbridge.
I reckon there was a lot of IP sharing, and Jim Keller of course.
"early AMD64 and Alpha processors were designed to be pin compatible."
Close enough. See Athlon, Hypertransport, and such.
Start at e.g. https://en.wikipedia.org/wiki/Athlon
"The Athlon architecture also used the EV6 bus licensed from DEC as its main system bus. Intel required licensing to use the GTL+ bus used by its Slot 1 Pentium II and later processors. By licensing the EV6 bus used by the Alpha line of processors from DEC, AMD was able to develop its own chipsets and motherboards, and avoid being dependent on licensing from its direct competitor."
As it is .Not spends about 30% in kernel according to TaskManager when loaded and working hard, how much will this cripple .Not, M$ pushes the fact that the code is secure, and this security is done in the kernel.
It is certainly going to be amusing to watch the fallout from this,
It's the move to and from kernel that is penalized, time spent inside kernel and time spent outside kernel isn't penalized. Of course, hardly any system monitoring programs will tell you how many syscalls or context switches different programs cause.
> Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.
No I won't because I understand how a fucking kernel works. This is a remarkably stupid comparison; especially when we know how kernels work. We can evidence their existence, there are books relating to the design of them by mere mortals. They do not care about trivial areas of our lives!
I'm more mad about this than the 20-30% of CPU limiting that's going to go on.
This post has been deleted by its author
*slow clap*
And this hoo-haa triggered this memory of the Usenet Oracle and Windows 95...
The original can be found here : https://internetoracle.org/special/windoze2.cgi
The Usenet Oracle has pondered your question deeply.
Your question was:
> O great Oracle, the one who sees all and knows all, please accept
> this humble question from thy grovelling supplicant...
>
> Why is Windows 95 Beta so bug-ridden it's not funny?
And in response, thus spake the Oracle:
} THE SCENE: A dark antechamber of the Gates estate, dimly lit by three
} 20" monitors suspended from the ceiling. In the middle of the room is
} a Pentium/100Hz, sheathed in a black casing. Three programmers dance
} around the machine, chanting horribly. Their pale, clammy complexion
} is cast hideously by the light of the monitors, rendered even more
} repugnant to the watchful eye bye the 60Hz flicker of the monitors.
}
} FIRST PROGRAMMER: Thrice the brinded net hath mewed.
}
} SECOND PROGRAMMER: Thrice, and once the Warp-pig whined.
}
} THIRD PROGRAMMER: MacHarpier cries. 'Tis time, 'tis time!
}
} FIRST: Round about the terminal go;
} In the poisoned upgrade throw.
} Code, which by a student done
} In minutes numbering sixty-one.
} Run-time error, protection fault,
} Crash ye first, crash ye shalt.
}
} ALL [as they dance around the Pentium]:
} Double, double, toil and trouble;
} Tempers burn and data bubble.
}
} SECOND: Fillet of a Sound Card bake,
} In the Pentium no sound make;
} Point of arrow, click of mouse,
} Scream of user, frightened spouse,
} OS/2's net use appeal,
} Steve Jobs' look and Wozniak's feel.
} For a charm of powerful trouble,
} Like a hell-broth boil and bubble.
}
} ALL: Double, double, toil and trouble;
} Tempers burn and data bubble.
}
} THIRD: Click "Start" button, speed of slug,
} You would think you forgot the plug.
} Multitasking, ha ha ho
} If just one worked you'd be good to go.
} This should grab those straggling few
} Who aren't using DOS 6.22.
} Now we shall the Mac eclipse,
} While curse words cross our users' lips.
} Leave the errors in so we can fix
} And sell more...Windows 96!
} And so we will release the Beta
} For corruption of their data.
}
} ALL: Double, double, toil and trouble;
} Users buy, our profits double.
}
} SECOND: Compile it with errors through,
} Since the users have no clue.
}
} [Enter BillGate to the other three programmers.]
}
} BillGate: O, well done! I commend your pains,
} And everyone shall share i' the gains.
} And now about the program get,
} But NEVER use it on OUR net.
} Security is scarce put in.
} [Beeps of PONG heard in the background.]
} [Exit BillGate.]
}
} SECOND WITCH: By the usage of my UMBs
} Wicked Windows this way comes.
} Open locks,
} Whoever knocks!
}
} [Fade to black.]
}
} Remember, Obsolescence isn't an accident, it's an art form.
}
} You owe the Oracle a signed, handwritten manuscript of MacBeth, and a
} copy of the Windows upgrade for the P6.
Why has no one asked the most critical question... do I need to patch my Pi?
Also, given the number of recent SNAFU's like this and Apple's login cock-up etc... I'd like to request a new +1 level of FAIL icon so that we can ring in 2018 with a new, appropriate level of numbnuttedness that the existing FAIL icon er... fails to encapsulate this new level.. Something like a double face palm icon?
Many years ago when I was a hardware developer we used to call this the Intel Factor. In the spec sheets you used to get min / typical / max figures. You knew that when the production chips came to replace the test ones the figures would be the least advantageous. You had to always design for the very worse case + 10%
And for that matter, my 8 racks of Intel-based servers in the server room?
Seriously, that was my first thought.
If this were a car, and, under certain circumstances the brakes were applied without instruction from the driver, there would be a recall, and the problem would be fixed, with the manufacturer taking the financial hit.
Why is it different with computer hardware? Why does the world just shrug its shoulders and just go "Oh well"?
I've got a lovely Lenovo I3 laptop that runs Linux Mint beautifully, and I'm delighted with it. This has majorly pissed me off.
In the server room, we run racks of Wintel HP servers running mission-critical SCADA software, and it looks like we're suddenly going to get a lot less bang for our buck.
Why can't we return them the manufacturer, who in turn returns them to Intel?
It's a rhetorical question, I suppose. I mean, what would they be replaced with, since Intel has no iron that, you know, actually works *properly*.
But that's the point, isn't it. Why should we put up with this?
Mistakes happen, of course. But there's no reason why we should just "put up with it".
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date: Mon Dec 4 15:07:34 2017 +0100
x86/mm/pti: Disable global pages if PAGE_TABLE_ISOLATION=y
Global pages stay in the TLB across context switches. Since all contexts share the same kernel mapping, these mappings are marked as global pages so kernel entries in the TLB are not flushed out on a context switch.
But, even having these entries in the TLB opens up something that an attacker can use, such as the double-page-fault attack
...
Funny, I thought video conversion would be minimally hit, as it consists mostly of:
read(very many bytes); process (very long cpu intensive code); write(very many bytes)
Where, if the read and write are implemented as sending big requests to the kernel, should be minimally affected. The processing portion of it is surely 99% of the whole processing time anyway?
I could believe things like a database would slow down, when it's hopping all over the place on disk looking for/writing data. I could believe facebook slows down alot, because browsers are doing lots of itsy bitsy tiny reads and writes to both disk and net, and lots of small updates of the screen to animate all the gifs and what not.
It's already been established on Phoronix that games are not affected - if it's mostly user mode code there isn't going to be a noticeable impact. I would have thought video editing/transcoding also fit into that category.
Personally I'm more worried about virtualisation.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
