Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign | Pe

SINep

SINep

Veteran XX
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/
 
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.
 
:rofl: What a fucking disaster. My god.

5% to 30% performance loss?
 
Last edited:
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:
the bug is present in modern Intel processors produced in the past decade.
Click to expand...

Validuz said:
:rofl: What a fucking disaster. My god.

5% to 30% performance loss?
Click to expand...

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
 
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
 
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.
 
MC Hamster said:
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.
Click to expand...

no one gonna read that shit you faggot
 
You must log in or register to reply here.
Back
Top