EnglishGermanFrenchRussianItalianSpanish
Log inRegister
 
intel cpu bug found
Post new topic Reply to topic Goto page 1, 2, 3, 4, 5  Next
View previous topic :: View next topic
Author Message
apogee



MEDALMEDALMEDAL

Joined: 22 Jul 2004
Posts: 1099 on topic
Location: Location Location
Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 01:38    Post subject: intel cpu bug found Reply with quote Print

going to mean reduced performance

lovely....

Back to top
View user's profile Send private message
Olterin



MEDALMEDAL

Joined: 27 Feb 2009
Posts: 602 on topic
Location: ... is as usual, the wrong one
Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 01:54    Post subject: Reply with quote Print

... That sounds like quite the "bug" Neutral

Lovely...


_________________
From Nothing, a DiD by Scion Drakhar
Tranquillity(indefinitely on hold)
"Do or do not, there is no try"
"My Other Overwhelming Mixed Assault Fleet is a Brigantine" -Seleucius, commenting on my ship naming scheme
Back to top
View user's profile Send private message
UniTrader
Moderator (Script&Mod)
Moderator (Script&Mod)

MEDAL

Joined: 20 Nov 2005
Posts: 13815 on topic

Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 02:04    Post subject: Reply with quote Print

i am currently glad i have decided to use amd when i built my new rig last year...


_________________
if not stated otherwise everything i post is licensed under WTFPL

Ich mache keine S&M-Auftragsarbeiten, aber wenn es fragen gibt wie man etwas umsetzen kann helfe ich gerne weiter Wink

I wont do Script&Mod Request work, but if there are questions how to do something i will GLaDly help Wink
Back to top
View user's profile Send private message
ezra-r





Joined: 14 Oct 2005
Posts: 3064 on topic

Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 02:24    Post subject: Reply with quote Print

it would be nice to know which exact models are affected.


_________________
Ideas: * Revamp Miner Profession
X3 mods: Shielding Upgrade *Pirate Patrols,Khaa'k Invasions
Creative: Nula The Xenon
Back to top
View user's profile Send private message
red assassin





Joined: 15 Feb 2004
Posts: 593 on topic
Location: Oxford, UK
Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 02:44    Post subject: Reply with quote Print

ezra-r wrote:
it would be nice to know which exact models are affected.

The short version is "yes".

The longer version is - any processor with any form of speculative execution is potentially vulnerable to some forms of the attack. This is pretty much every modern non-embedded CPU at least, and potentially includes a lot of embedded chips as well. From what's been released so far I would say that it looks highly likely that any Intel processor is vulnerable to the simpler/more obvious forms of the attack.

Project Zero have been able to demonstrate the attack on an AMD processor as well, despite AMD's claims not to be vulnerable, in the very specific circumstances that user-controlled code can be inserted into the kernel (in this case, via the eBPF JIT kernel module). There are likely to be other variants of these circumstances discovered. This is why I say I suspect nearly every processor is going to be vulnerable to some forms of the attack, just not the easy version that applies to Intel.

Ultimately this comes down to the fact that making your CPU faster in some, but not quite all, circumstances necessarily leaks information about what those circumstances are - this is the cost of caching. I imagine variants of this attack will continue to pop up for years, despite the performance-costly mitigations installed in the latest versions of the Linux and NT kernels.


_________________
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way
Back to top
View user's profile Send private message
kohlrak





Joined: 28 Dec 2017



modified
PostPosted: Thu, 4. Jan 18, 03:21    Post subject: Reply with quote Print

I'm a bit more curious about what they plan on doing. First off, how is the memory vulnerable? Is it writable or just readable? How do they plan on hiding the kernel from the user? Better question yet, how did this get by for so long without anyone noticing? I thought PMODE was effectively established long ago and that you can't read ring 0 from a lower ring.

EDIT: Apparently intel's admitting the readable bit, but then i'm guessing this has more to do with PAE mode than anything. I never used it, tbh, so I don't know how it works. In theory, everyone who designs kernels should've known about this. Intel even says that it's documented. And they're right that this affects almost all, if not all, processors out there. I'm not sure if it affects ARMs (androids and iPhones use this) or not. I remember thumb mode ARM have separate code and data RAMs (thus the code is only readable by privileged instructions to begin with), but i'm not sure if that's true with the mainline ARMs.



Last edited by kohlrak on Thu, 4. Jan 18, 03:35; edited 1 time in total
Back to top
View user's profile Send private message
red assassin





Joined: 15 Feb 2004
Posts: 593 on topic
Location: Oxford, UK
Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 03:34    Post subject: Reply with quote Print

There's really two separate issues here. See https://meltdownattack.com/ for more. Both of them are read issues only, there's no indication that any of this can be used to write.

"Meltdown" (sigh, everything needs a cool name now) is a flaw in Intel's microarchitecture which allows data from ring 0 to leak into the processor cache (from which it can be extracted via timing attacks) via careful manipulation of speculative execution. The privileged data is never explicitly accessible to the unprivileged process, but it alters the processor state in detectable ways. This is fixed in current development versions of the Linux and NT kernels by a method referred to as "KAISER", which scrubs a lot of processor state when transitioning from kernel to user mode, at the cost of performance (because that cached data is cached for a reason!).

"Spectre" is a more general expression of the fact that modern CPUs do speculative execution, and in some cases you can exploit that to leak data you shouldn't be able to via timing attacks. This doesn't allow crossing privileges directly, but in some cases you can do stuff like ask the kernel to do something vulnerable and time the result. There is no easy, single mitigation for this issue - it's a function of how CPUs work, and the only real approach is to try and scrub vulnerable code patterns from applications. This is going to be with us for a long time and there will be new and exciting variants of it appearing, I'm sure.


_________________
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way
Back to top
View user's profile Send private message
kohlrak





Joined: 28 Dec 2017



PostPosted: Thu, 4. Jan 18, 03:41    Post subject: Reply with quote Print

Firstly, Linux is open source, so I don't see why that's an issue for Linux. Secondly, the kernels are usually available in their non-running form to any process, anyway. You should build your kernel with the assumption that the attacker has access to it. Properly gate your kernel calls with syscalls and mind your own callstack usage and they shouldn't get in.

Back to top
View user's profile Send private message
red assassin





Joined: 15 Feb 2004
Posts: 593 on topic
Location: Oxford, UK
Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 03:52    Post subject: Reply with quote Print

This isn't necessarily about being able to read the kernel's code (although that can be useful too in case of ASLR and other similar mitigations) - it allows you to read *any* privileged memory. That's incredibly powerful in enabling exploitation of other kernel bugs, but it also allows you to read sensitive data directly. Linux, for example, maps the entire physical memory into the kernel's virtual address space, meaning you can read memory from any process on the system as well as the kernel using this attack.
edit: I'll be quite surprised if somebody doesn't get Meltdown working from JavaScript in some form, and the idea of random JavaScript being able to read any memory on your system should be properly scary.


_________________
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way
Back to top
View user's profile Send private message
burger1





Joined: 21 Aug 2009
Posts: 476 on topic
Location: Canada
Thank you for registering your game
modified
PostPosted: Thu, 4. Jan 18, 04:03    Post subject: Reply with quote Print

AMD is getting "fixed" also. Maybe it's their way of getting people to buy new cpus since there really hasn't been much change in terms of speed for years.


UniTrader wrote:
i am currently glad i have decided to use amd when i built my new rig last year...


https://www.forbes.com/sites/davealtavilla/2018/01/03/intel-processor-bug-leaves-all-current-chips-vulnerable-and-its-fix-saps-performance/#42e639a8570a

To be clear, these software patches are being released and will apply this fix for all processors, regardless of processor type in the targeted system. In other words, though AMD processors are not effected and are not subject to this vulnerability, applying the patch would regardless also result in possible performance degradation. Thomas Lendacky, a member of the Linux OS group at AMD reports “AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.” As such, AMD is currently not recommending patching systems for this Intel bug, though again, it will likely be pushed from OS vendors, regardless.



Last edited by burger1 on Thu, 4. Jan 18, 04:04; edited 1 time in total
Back to top
View user's profile Send private message
kohlrak





Joined: 28 Dec 2017



PostPosted: Thu, 4. Jan 18, 04:03    Post subject: Reply with quote Print

Most people, out of laziness (or maybe due to compiled code restrictions regarding the segment registers), do map the entire memory to kernel address space. They shouldln't, though. Ring 0 can use a lower ring's segment, IIRC.

Moreover, these OSes typically have something similar to the HOOKS API, which essentially allows any program to access any other program's RAM, regardless (which is why so many games are trying to implement cheat protection). Realistically, this isn't offering us anything new aside from the realization that people have been doing things wrong for a very long time. By the looks of things, what they're planning to do to solve it not only won't solve it, but doesn't even attempt to address the problem.

In other words, we have new exploits that help people do the things that they could already do, anyway. Anyone who's shocked by this was living under a rock. Even Intel seems to be approaching it this way.

EDIT:

Quote:
edit: I'll be quite surprised if somebody doesn't get Meltdown working from JavaScript in some form, and the idea of random JavaScript being able to read any memory on your system should be properly scary.


The idea of javascript even reading the browser's memory is scary enough to me. We've been overly kind with what these scripts are able to do. The irony is that alot of these things had security in mind originally, but fell apart later, because I guess that's intel's job?

EDIT2: I'm not finding any way for javascript code to do that, actually, though a bad browser could have a bug or "feature" that would allow it. Javascript doesn't allow pointer manipulation.

Back to top
View user's profile Send private message
red assassin





Joined: 15 Feb 2004
Posts: 593 on topic
Location: Oxford, UK
Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 04:18    Post subject: Reply with quote Print

burger1 wrote:
AMD is getting "fixed" also. Maybe it's their way of getting people to buy new cpus since there really hasn't been much change in terms of speed for years.


https://www.forbes.com/sites/davealtavilla/2018/01/03/intel-processor-bug-leaves-all-current-chips-vulnerable-and-its-fix-saps-performance/#42e639a8570a

To be clear, these software patches are being released and will apply this fix for all processors, regardless of processor type in the targeted system. In other words, though AMD processors are not effected and are not subject to this vulnerability, applying the patch would regardless also result in possible performance degradation. Thomas Lendacky, a member of the Linux OS group at AMD reports “AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.” As such, AMD is currently not recommending patching systems for this Intel bug, though again, it will likely be pushed from OS vendors, regardless.

The Meltdown mitigation is not applied to AMD processors on Linux - that quote from Lendacky is attached to a patch which makes exactly that change. I imagine NT will do the same.

There is no central mitigation for Spectre, which does affect AMD processors as well.


kohlrak wrote:
Most people, out of laziness (or maybe due to compiled code restrictions regarding the segment registers), do map the entire memory to kernel address space. They shouldln't, though. Ring 0 can use a lower ring's segment, IIRC.

Moreover, these OSes typically have something similar to the HOOKS API, which essentially allows any program to access any other program's RAM, regardless (which is why so many games are trying to implement cheat protection). Realistically, this isn't offering us anything new aside from the realization that people have been doing things wrong for a very long time. By the looks of things, what they're planning to do to solve it not only won't solve it, but doesn't even attempt to address the problem.

In other words, we have new exploits that help people do the things that they could already do, anyway. Anyone who's shocked by this was living under a rock. Even Intel seems to be approaching it this way.

EDIT:

The idea of javascript even reading the browser's memory is scary enough to me. We've been overly kind with what these scripts are able to do. The irony is that alot of these things had security in mind originally, but fell apart later, because I guess that's intel's job?

The gist I'm getting here is "other security flaws exist so we shouldn't patch security flaws". This seems like a flawed argument to me. Sure, there'll be other bugs, and we should fix those too. But granting the ability to any executing code to read any memory on the system, which appears to be the effect of Meltdown, undoes pretty much the entire separation of privileges security model. All of the work done by sandboxing, user accounts, elevation levels, the kernel, etc etc in isolating sensitive bits of the system from other parts - user credentials, crypt keys, the user's actual data, etc etc - goes out of the window in one fell swoop. If you work hard enough you can get past any of those methods of isolation, but it's hard - Meltdown makes all of it easy in one handy attack.

JavaScript can't read browser memory without some form of exploit.


_________________
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way
Back to top
View user's profile Send private message
kohlrak





Joined: 28 Dec 2017



PostPosted: Thu, 4. Jan 18, 04:31    Post subject: Reply with quote Print

red assassin wrote:
kohlrak wrote:
Most people, out of laziness (or maybe due to compiled code restrictions regarding the segment registers), do map the entire memory to kernel address space. They shouldln't, though. Ring 0 can use a lower ring's segment, IIRC.

Moreover, these OSes typically have something similar to the HOOKS API, which essentially allows any program to access any other program's RAM, regardless (which is why so many games are trying to implement cheat protection). Realistically, this isn't offering us anything new aside from the realization that people have been doing things wrong for a very long time. By the looks of things, what they're planning to do to solve it not only won't solve it, but doesn't even attempt to address the problem.

In other words, we have new exploits that help people do the things that they could already do, anyway. Anyone who's shocked by this was living under a rock. Even Intel seems to be approaching it this way.

EDIT:

The idea of javascript even reading the browser's memory is scary enough to me. We've been overly kind with what these scripts are able to do. The irony is that alot of these things had security in mind originally, but fell apart later, because I guess that's intel's job?

The gist I'm getting here is "other security flaws exist so we shouldn't patch security flaws". This seems like a flawed argument to me. Sure, there'll be other bugs, and we should fix those too. But granting the ability to any executing code to read any memory on the system, which appears to be the effect of Meltdown, undoes pretty much the entire separation of privileges security model. All of the work done by sandboxing, user accounts, elevation levels, the kernel, etc etc in isolating sensitive bits of the system from other parts - user credentials, crypt keys, the user's actual data, etc etc - goes out of the window in one fell swoop. If you work hard enough you can get past any of those methods of isolation, but it's hard - Meltdown makes all of it easy in one handy attack.

JavaScript can't read browser memory without some form of exploit.


Let me tell you what you should read from it: there's a proper layer for security, and what we're talking about isn't it.

When OSes, in practice, are providing their own methods of thwarting the protection, why is the cache thing even an issue? The consistent statement of the OSDEVs is that reading the kernel's memory, as well as 2 ring 3 programs reading each other's memories, is not a problem. Only now has the message changed, and it sounds more like a response to fear of the media more than actual concern. Intel put the cache control instructions in the processor for a reason. If you're not OK with something being cached, you shouldn't allow it to be cached. It's up to the kernel devs to make this happen, not intel.

The OSes we use are inherently insecure. Proper gating techniques work for code execution. As for read level, even before caching it was insecure. It's the OS devs that made it insecure, not intel. The instructions there to prevent these issue always existed, except no one bothered to implement them, even to the degree that the same OS Devs made it so you can thwart the read protection without the cache issues, and this was intentional.

There never was a bug: people just made incorrect assumptions: the OS devs for assuming they didn't need to use the cache management instructions, and everyone else for assuming that it wasn't an OS design flaw.

Back to top
View user's profile Send private message
pjknibbs



MEDALMEDALMEDAL

Joined: 06 Nov 2002
Posts: 28273 on topic
Location: UK
Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 10:24    Post subject: Reply with quote Print

kohlrak wrote:

When OSes, in practice, are providing their own methods of thwarting the protection, why is the cache thing even an issue? The consistent statement of the OSDEVs is that reading the kernel's memory, as well as 2 ring 3 programs reading each other's memories, is not a problem.


Think I'll need a [citation needed] on that? There was a hook API in the Windows API back in 16-bit days that allowed a process to read another process's memory, but I'm not sure the same exists in Win32. In addition, it's never been possible for Ring 3 code to read Ring 0 memory (outside of CPU bugs and timing attacks)--the Ring 0 memory being *visible* in the Ring 3 process doesn't mean it's readable, what *should* happen is that you get an access violation error if you attempt it.

Back to top
View user's profile Send private message
red assassin





Joined: 15 Feb 2004
Posts: 593 on topic
Location: Oxford, UK
Thank you for registering your game
PostPosted: Thu, 4. Jan 18, 11:47    Post subject: Reply with quote Print

pjknibbs wrote:
Think I'll need a [citation needed] on that? There was a hook API in the Windows API back in 16-bit days that allowed a process to read another process's memory, but I'm not sure the same exists in Win32. In addition, it's never been possible for Ring 3 code to read Ring 0 memory (outside of CPU bugs and timing attacks)--the Ring 0 memory being *visible* in the Ring 3 process doesn't mean it's readable, what *should* happen is that you get an access violation error if you attempt it.

There are APIs like the helpfully named ReadProcessMemory in Win32, but that requires specific privileges and doesn't just allow you to crash around reading anything's memory. kohlrak seems to be unaware of the last decade of work on the separation of privileges in Windows - this would have been a fairly fair characterisation in the XP days when basically everything was administrator and you could load unsigned drivers, but we're a long way from that now. As far as I know Linux has never been as bad as claimed (though they've certainly tightened up kernel isolation too).

kohlrak wrote:
There never was a bug: people just made incorrect assumptions: the OS devs for assuming they didn't need to use the cache management instructions, and everyone else for assuming that it wasn't an OS design flaw.

Isn't "people just made incorrect assumptions" exactly what a bug is? Just because you think this is obvious in hindsight doesn't mean it was - there's a giant gulf between "this is documented behaviour" and "this documented behaviour allows the following security breaches", and the fact that it's been two decades since Intel introduced speculative execution in the Pentium Pro before anybody figured this out should demonstrate that. I think this particular behaviour ("Meltdown") is surprising, and not an obvious consequence of the way processors work, especially given AMD isn't vulnerable. (The fact that Spectre like attacks are possible is less surprising, and they're also a lot fiddlier to pull off.) I also don't think you can pin all the blame on OS developers, given x86 provides instructions (SYSENTER family) specifically to allow getting to ring 0 without expensive operations like interrupts and cache flushes - this is clearly the way it's meant to be used, or SYSENTER etc would just flush caches.


_________________
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic Reply to topic Goto page 1, 2, 3, 4, 5  Next
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
Control Panel
Login Data
The time now is Tue, 25. Sep 18, 14:39

All times are GMT + 2 Hours

[ Disclaimer / Impressum ] | [ Privacy Policy / Datenschutz ]

Board Security

Copyright © EGOSOFT 1989-2018
Powered by phpBB © 2001, 2005 phpBB Group
Template created by Avatar & BurnIt!
Debug: page generation = 0.15745 seconds, sql queries = 29