VeteranXX
|
Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign | Pe
Front Page Article
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 to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.
Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features such as PCID to reduce the performance hit. Your mileage may vary.
Best case: 17% slowdown
Worst case: 23% slowdown
The Register (@TheRegister) January 2, 2018
Similar operating systems, such as Apple's 64-bit macOS, will also need to be updated the flaw is in the Intel x86-64 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder.
Details of the vulnerability within Intel's silicon are under wraps: an embargo on the specifics is due to lift early this month, perhaps in time for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux kernel are available for all to see but comments in the source code have been redacted to obfuscate the issue.
However, some details of the flaw have surfaced, and so this is what we know.
More:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
|
|
|
VeteranXV
|
built in obsolescence, everyone buy a new computer.
|
|
|
VeteranXX
|
Quote:
Originally Posted by GreyGhost
From page 2.
|
I posted it on the news page; didn't browse the forums today.
|
|
|
VeteranXX Contributor
|
logging into work early for this they rebooted our clouds
|
|
|
VeteranXV
|
lol if you work in IT right now. What a disaster.
|
|
|
VeteranXX
|
If I had one of these my feeling is I would take it back to the shop and ask for a refund - doesn't perform as specified or advertised.
|
|
|
VeteranXX Contributor
|
Quote:
the bug is present in modern Intel processors produced in the past decade.
|
fuuuuuuuuuuuuuuuuuuuuuu
|
|
|
VeteranXX Contributor
|
What a ****ing disaster. My god.
5% to 30% performance loss?
|
|
Last edited by Validuz; 01-03-2018 at 23:24..
|
VeteranXX Contributor
|
a lot longer than that. Everything since '95, excepting Itanium (lol) and pre-2013 Atoms. Spectre hits AMD and ARM as well, so basically: nothing is safe.
Performance loss is because you basically need to ditch out-of-order execution, which is particularly handy in multi-core systems.
|
|
Last edited by MC Hamster; 01-03-2018 at 23:31..
|
VeteranXX
|
Quote:
the bug is present in modern Intel processors produced in the past decade.
|
Quote:
Originally Posted by Validuz
What a ****ing disaster. My god.
5% to 30% performance loss?
|
Well then we have already been more than happy about living with it so why worry now? Not a problem at all. This will be 5-30% loss on a certain process, not on the overall system anyway.
Just fix it next gen and enjoy a free boost
|
|
|
VeteranXX
|
is there a way to not have my computer auto patch this
how can i disable windows 10 installing updates and rebooting my system while i sleep
wtf
id rather have a buggy system than one slowed down by gay updates i dont consent to
|
|
|
VeteranXX Contributor
|
As I understand it (and forgive me because it's been a long time since my Comp Sci days), it basically comes down to avoiding "wasted" CPU cycles.
Back in Ye Olden Dayes, when I was writing assembler code on SPARC boxes, you had two different registers you could send commands to be processed in the CPU. One was the command to be executed, the other was the next command to be executed. When it finished with one, it could flip them over and start working on the next while it got the other register loaded and ready to go.
The problem there arises when that next command relies on some output from the current. EG when you have "a+b=c", then "c+1=d". Assuming you know the values of a and b, then that first command is fine, but the second one is already loaded into the CPU as well, before 'c' has actually been resolved, so when it comes time to execute that, the variable is still unknown and you can't get a sensible result out of it.
Similarly, if you have some sort of control structure (eg a loop), you can inadvertently wind up pulling in the next line of code outside that loop before the system realises it needs to go back to an earlier instruction.
As a result, you need to fill your code with "nops" ('no operation') to make sure the CPU doesn't process a 'wrong' instruction.
In a multi-processor/multi-core system, that issue gets compounded, even when you're being all proper and multi-threading properly.
Out-of-order execution makes attempts to let you use some of those otherwise wasted cycles, by pulling in other instructions (that don't rely on unknown data) even if they're not really supposed to be getting calculated yet, and then re-assembling it all in the right order. This is the sort of stuff that gets stored in the processor cache.
My guess with this (and I haven't really delved right into it) is that the exploits target that cache to read registers that aren't necessarily 'owned' by the processes in question, resulting in data leaks.
|
|
|
VeteranXX Contributor
|
Quote:
Originally Posted by MC Hamster
As I understand it (and forgive me because it's been a long time since my Comp Sci days), it basically comes down to avoiding "wasted" CPU cycles.
Back in Ye Olden Dayes, when I was writing assembler code on SPARC boxes, you had two different registers you could send commands to be processed in the CPU. One was the command to be executed, the other was the next command to be executed. When it finished with one, it could flip them over and start working on the next while it got the other register loaded and ready to go.
The problem there arises when that next command relies on some output from the current. EG when you have "a+b=c", then "c+1=d". Assuming you know the values of a and b, then that first command is fine, but the second one is already loaded into the CPU as well, before 'c' has actually been resolved, so when it comes time to execute that, the variable is still unknown and you can't get a sensible result out of it.
Similarly, if you have some sort of control structure (eg a loop), you can inadvertently wind up pulling in the next line of code outside that loop before the system realises it needs to go back to an earlier instruction.
As a result, you need to fill your code with "nops" ('no operation') to make sure the CPU doesn't process a 'wrong' instruction.
In a multi-processor/multi-core system, that issue gets compounded, even when you're being all proper and multi-threading properly.
Out-of-order execution makes attempts to let you use some of those otherwise wasted cycles, by pulling in other instructions (that don't rely on unknown data) even if they're not really supposed to be getting calculated yet, and then re-assembling it all in the right order. This is the sort of stuff that gets stored in the processor cache.
My guess with this (and I haven't really delved right into it) is that the exploits target that cache to read registers that aren't necessarily 'owned' by the processes in question, resulting in data leaks.
|
no one gonna read that **** you ******
|
|
|
VeteranXX Contributor
|
Quote:
Originally Posted by Highfive
no one gonna read that **** you ******
|
As much as this place has gone downhill in recent years, not everyone here has the attention span of a toddler on amphetamines. There are some that may
|
|
|
VeteranXX Contributor
|
Quote:
Originally Posted by Highfive
no one gonna read that **** you ******
|
I read that **** you ******.
|
|
|
VeteranXX
|
tl;dr
Good news is AMD stock got a bump out of this.
|
|
|
VeteranXX
|
Quote:
Originally Posted by Highfive
no one gonna read that **** you ******
|
i read it
still rubbing my nips
thank u
|
|
|
VeteranXX
|
Quote:
Originally Posted by Flash
tl;dr
Good news is AMD stock got a bump out of this.
|
ODIO, WHERE ARE U?
|
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
AGENT: claudebot / Y
All times are GMT -4. The time now is 15:58.
|