Personal computing discussed

Moderators: Flying Fox, morphine

  • 1
  • 2
  • 3
  • 4
  • 5
  • 8
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10725
Joined: Tue Aug 27, 2002 6:35 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 2:40 pm

Ninjitsu wrote:
They seem to be suggesting that there's too much conflicting information at the moment, and that 30% perf hits are overstated.


A lot of that is from micro-benchmarks that are largely synthetic and are intended to illustrate the impact where it's directly felt. The hit is also dependent on the specific variant of micro-architecture: just because the Intel CPUs since Westmere finally have ASIDs doesn't mean that the performance using them is identical. And if you don't have PCID support at all, that's more pain.

It really comes down to the workload: the more syscalls your code does, the worse it is. It's impossible to just give one number, computationally intense stuff that sits in tight execution loops shouldn't show any discernible difference (like prime95). If you are constantly doing I/O and stuff like a database, you'll probably feel it hard.

JBI wrote:
You're probably right, but Zen is enough of a departure from Bulldozer/Piledriver design that I don't think we can take it for granted.


https://lkml.org/lkml/2017/12/27/2

AMD guy claims "AMD processors" as a whole.

The real question is what the release kernels are going to look like: the AMD guy supplied a patch to remove AMD from inclusion. It's all in Torvalds hands I guess, but I mean, why not be cautious? I keep saying that this happened fast, but I can't stress that enough. You don't usually see vague theoretical murmurings evolve into END-OF-THE-!%$*-WORLD in like less than two years. I mean, if someone can manage to do this embargoed thing in javascript, it's universal heartbleed "READ ALL THE THINGS" at a minimum.

when the timeline is:
Early-mid 2016: "Hey, that intel micro-architecture, prefetch seems fishy, and oh wow, what about-"
Late-2016: "It's definitely possible to detect side-channel information about kernel addresses"
Early-2017: "So like now there are actually three different ways to potentially defeat KASLR out there, we're going to have to get serious about actually unmapping kernel space guys. Yes, I know..."
Mid-2017: "So I couldn't *ACTUALLY* read kernel memory, which is good I guess!"
Late-2017: "We're unmapping kernel space. Now. It's happening. Deal with it. Happy Holidays?"

I mean, yes, this about micro-architecture, so yes, AMD is automatically different and they are (presumably officially) saying "We're in the clear guys!", but I mean, wow. Do we really think the well is dry with this new concept/technique? After it produced such a bounty? Or should we just bunker down, take the hit, and accept that this time has finally come?

I mean, this isn't just AMD, right? If two-three years from now Intel says "we got this, it's all safe, we're good, unleash us!" are you -sure- we're not going to get bit? I ain't. And, mind you, KASLR has got so many holes that it's been basically hopeless anyway. Having the have perfect AS isolation instead of privilege-shackles might just be the better way forward anyway, right? So, rip off the band-aid, and force the vendors to adapt. It might never be *quite* as good, but we're likely to make it much less worse in future architectures.

EDIT: Yeah, What Ryu and chuckula say: KASLR has *many* problems so maybe we just ought to make it impossible for userspace to *EVER* see kernelspace instead of hoping our strict ruleset of "no peeking!" and hand-slapping won't ever have any holes. Like I said, should we trust Intel when they've "fixed the (specific) glitch"? If not, why would we trust AMD now? If we can make it less painful in newer architectures to have real isolation, isn't that just superior overall?
 
DragonDaddyBear
Gerbil Elite
Posts: 706
Joined: Fri Jan 30, 2009 8:01 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 3:07 pm

What are the odds that this could be used to extract an encryption key or password? That, to me, is probably the scariest scenario as it that information could be used to masquerade as a legitimate user or get what should be otherwise encrypted information out of the system.
 
jackbomb
Gerbil XP
Posts: 317
Joined: Tue Aug 12, 2008 10:25 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 3:37 pm

I'm glad that I went back to Win7 last week. I am so going to hide that patch, as moronic as that decision may be from a security standpoint.
Like a good neighbor jackbomb is there.
 
Kougar
Minister of Gerbil Affairs
Posts: 2253
Joined: Tue Dec 02, 2008 2:12 am
Location: Texas

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 6:10 pm

Complicated indeed, there are apparently two attack vectors labeled Meltdown and Spectre. Meltdown has to do with reading higher privilege data and is what is being fixed in the patches, but Spectre involves reading memory out of other running programs.

Wired claims Spectre affects AMD and ARM chips as well, which means most mobile phones would also be affected.

https://www.wired.com/story/critical-in ... computers/
 
fhohj
Gerbil Team Leader
Posts: 232
Joined: Tue Dec 10, 2013 4:10 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 6:44 pm

Does anybody have any idea how this bug will affect Denuvo (specifically with current and older implementations) and such?

And when I say bug, I do mean the mandatory patch.
Last edited by fhohj on Wed Jan 03, 2018 6:50 pm, edited 1 time in total.
 
DragonDaddyBear
Gerbil Elite
Posts: 706
Joined: Fri Jan 30, 2009 8:01 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 6:49 pm

fhohj wrote:
Does anybody have any idea how this bug will affect Denuvo (specifically with current and older implementations) and such?

It looks like Spectre, not being patched and Intel specific, could be used to do that. (I think I got that right, still murky.) But I imagine that encryption keys are unique to each system.
 
fhohj
Gerbil Team Leader
Posts: 232
Joined: Tue Dec 10, 2013 4:10 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 6:51 pm

DragonDaddyBear wrote:
fhohj wrote:
Does anybody have any idea how this bug will affect Denuvo (specifically with current and older implementations) and such?

It looks like Spectre, not being patched and Intel specific, could be used to do that. (I think I got that right, still murky.) But I imagine that encryption keys are unique to each system.


Darn you got to me before my edit. I meant more what games with Denuvo will look like on the amount of hit they take from a performance perspective, than I did how this could be used to defeat Denuvo.
 
Redocbew
Gold subscriber
Gerbil Jedi
Posts: 1532
Joined: Sat Mar 15, 2014 11:44 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 6:52 pm

I'd expect these exploits to pose the same amount of risk to Denuvo as they would any other DRM happening purely in software. The cryptographic keys might get snooped, and so on. Otherwise it's mostly unrelated.

Ninja edit: In terms of performance I don't think anyone really knows yet, and it's likely to be very dependent on the specific workload.
Do not meddle in the affairs of archers, for they are subtle and you won't hear them coming.
 
Kougar
Minister of Gerbil Affairs
Posts: 2253
Joined: Tue Dec 02, 2008 2:12 am
Location: Texas

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 7:23 pm

More info on Spectre, as well as Meltdown https://spectreattack.com/
 
Redocbew
Gold subscriber
Gerbil Jedi
Posts: 1532
Joined: Sat Mar 15, 2014 11:44 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 7:37 pm

I wonder if anyone else finds it mildly amusing to see Rambus mentioned in these reports. To be fair, I suppose there's a pretty good chance it's not really the same company anymore, but if there was ever a company who just refused to die, then Rambus is most certainly it.
Do not meddle in the affairs of archers, for they are subtle and you won't hear them coming.
 
klok
Gerbil In Training
Posts: 1
Joined: Wed Nov 29, 2017 6:29 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 8:01 pm

From the spectre paper:
While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak.
 
just brew it!
Gold subscriber
Administrator
Posts: 50699
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 8:17 pm

klok wrote:
From the spectre paper:
While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak.

Pretty much.

It seems clear that these sorts of "side channel" attacks weren't even considered (at least not seriously...) when current CPU architectures were designed. Future architectures will certainly include improved ways of efficiently managing the user/kernel and user/user separation of virtual memory, to make things more resistant to these types of potential exploits without imposing a significant performance hit. Until then, we'll need to live with either the vulnerability or the performance penalty of the workaround.

And even if better solutions are implemented in silicon, the old, less secure (and/or less performant) method(s) will still need to be supported as an option, for backward compatibility with legacy OSes.
Nostalgia isn't what it used to be.
 
Ryu Connor
Gold subscriber
Global Moderator
Posts: 4283
Joined: Thu Dec 27, 2001 7:00 pm
Location: Marietta, GA
Contact:

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 8:45 pm

https://googleprojectzero.blogspot.co.a ... -side.html

Jann Horn, one of the finders of Meltdown had an interesting footnote in his breakdown of the vulnerability.

Other microarchitectures
Our research was relatively Haswell-centric so far. It would be interesting to see details e.g. on how the branch prediction of other modern processors works and how well it can be attacked.


Cue ominous music.

I have a feeling that one AMD developer submitting the patch to exclude AMD from KPTI may have inadvertently thrown down a gauntlet.
All of my written content here on TR does not represent or reflect the views of my employer or any reasonable human being. All content and actions are my own.
 
Redocbew
Gold subscriber
Gerbil Jedi
Posts: 1532
Joined: Sat Mar 15, 2014 11:44 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 8:49 pm

Yeah, it's looking like those in this thread who cautioned against branding this as "Intel-only", and that these two exploits are really just the proverbial tip of the iceberg are going to be proven right. Those in charge of damage control at Intel are likely grateful for that assuming they have time to stop and think about it. :P
Do not meddle in the affairs of archers, for they are subtle and you won't hear them coming.
 
just brew it!
Gold subscriber
Administrator
Posts: 50699
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 9:28 pm

Ryu Connor wrote:
I have a feeling that one AMD developer submitting the patch to exclude AMD from KPTI may have inadvertently thrown down a gauntlet.

Yeah... it is sounding like AMD may be immune to one specific variant of this type of attack, but not all.
Nostalgia isn't what it used to be.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1679
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 9:50 pm

It gets better!

https://access.redhat.com/security/vuln ... eexecution

Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).


So those of you with POWER chips... yes you get to join the party too.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
just brew it!
Gold subscriber
Administrator
Posts: 50699
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 10:29 pm

I started reading the Spectre paper. Holy crap, this is f*cking brilliant stuff.

They trick the JavaScript JIT compiler into generating code which will cause a branch mis-predict on a check for out-of-bounds array access. The result of that out-of-bounds access is then used to calculate the address of yet another memory access. Since the branch is mis-predicted, the CPU starts speculatively (and incorrectly) executing those two memory fetches before it figures out that the array bounds check has failed (and unwinds the internal register state back to the branch point).

The value isn't accessible directly to the exploit code (since the register state gets unwound), but the second memory access evicts a line from the CPU's data cache that depends on the value fetched by the first memory access. Additional code can then determine which cache line was evicted by timing how long it takes to access the elements of a previously cached array. Do this enough times, and you can figure out what the value at the first memory location is.

Wow.

Edit: Note - This is actually a separate issue from the kernel/user page table thing. It just happens to have speculative execution in common as one of the mechanisms being exploited.
Nostalgia isn't what it used to be.
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10725
Joined: Tue Aug 27, 2002 6:35 pm

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 9:00 am

JBI wrote:
I started reading the Spectre paper. Holy crap, this is f*cking brilliant stuff.


Yeah I spent so much time rhapsodizing about the impending meltdown imposed by what we now know as Meltdown, that I completely ignored the looming specter of Spectre. So focused on kernel space that I didn't really put any thought towards the implications for userspace, which we can't even hide. Eek!

I felt the same way, ingenious!

This new concept/technique is like, wow, I don't know, completely game-changing. What do we even compare it to?

It's amazing, reading all this stuff after they gave up early on the embargo: When you see a footnote that says "we've talked to right people at intel, and they promise to make lfence a full guarantee of even behind-the-scenes serialization." WOWZA!

^ That's them saying that the short-term hardware (i.e. ONE to THREE YEARS) response to this is a hardware-provided instruction cage for code sequences that we've pre-identified as potentially repurposable towards engineering the scenario that JBI described: "The result of that out-of-bounds access is then used to calculate the address of yet another memory access."

You can build these with JIT or other mechanisms that are intended to provide run-time code generation, or you can find them pre-existing by chance in available libraries.

Hence, all Intel is doing is providing a lock that can we put on boxes that we know to be bad, for what will probably be a negligible performance impact. That's the only part of it that's likely good news, the rest sucks: First off, this doesn't help with all the boxes that are already out there, an enormous amount that we're simply not going to be rid of anytime soon. Second off, it only helps if we correctly identify the known patterns (the gadgets) and then correctly lock them down. That's not trivial. Third off, it doesn't help us if there are other possible constructions, other patterns, by which attackers can massage this information out of the caches, which is unfortunately EXTREMELY likely--this is stuff so thoroughly baked into how the processor works and this technique is so new that's it's unfortunately virtually inevitable, our bounty, our harvest of sorrow, has just begun to be reaped! And, fourthly, this is essentially a kludge: we didn't remotely solve the real problem, which is that timing the caches can reveal information about speculative execution.

The real problem is going to require a -SERIOUS- and -WELL-THOUGHT- long-term hardware solution, i.e, we're probably talking about five years or more. You know, the horizon beyond which things are already hazy. Yikes!

So, in the short-term, wow. Companies like Google can lock up the known gadgets, make sure their engines don't build them, etc... But Google isn't most companies. And that's the hardware short-term, in the actual short-term, I don't know, do we think about how to seriously shake-and-break javascript this time around (degrading api timers didn't do diddly)?

Like I said, this is one of those things that's incomparable: honestly, this isn't even about painful solutions: what can we even do? :o :evil:
 
just brew it!
Gold subscriber
Administrator
Posts: 50699
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 9:39 am

Glorious wrote:
It's amazing, reading all this stuff after they gave up early on the embargo: When you see a footnote that says "we've talked to right people at intel, and they promise to make lfence a full guarantee of even behind-the-scenes serialization." WOWZA!

I suspect everyone's web experience is about to get slower as all the web browsers' JavaScript implementations get patched to mitigate Spectre. Without a bulletproof LFENCE implementation in hardware, the performance cost likely will not be negligible.
Nostalgia isn't what it used to be.
 
derFunkenstein
Gold subscriber
Gerbil God
Posts: 24183
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 9:55 am

just brew it! wrote:
klok wrote:
From the spectre paper:
While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak.

Pretty much.

It seems clear that these sorts of "side channel" attacks weren't even considered (at least not seriously...) when current CPU architectures were designed. Future architectures will certainly include improved ways of efficiently managing the user/kernel and user/user separation of virtual memory, to make things more resistant to these types of potential exploits without imposing a significant performance hit. Until then, we'll need to live with either the vulnerability or the performance penalty of the workaround.

And even if better solutions are implemented in silicon, the old, less secure (and/or less performant) method(s) will still need to be supported as an option, for backward compatibility with legacy OSes.

So why would AMD guy even spend time arguing about whether the Meltdown patches should be applied against AMD hardware? AMD claims the performance hit from KPTI is basically non existent and I feel like it's just a matter of time before someone can make Zen cores do things they supposedly shouldn't allow.
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1679
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 10:25 am

derFunkenstein wrote:
AMD claims the performance hit from KPTI is basically non existent and I feel like it's just a matter of time before someone can make Zen cores do things they supposedly shouldn't allow.


AMD argues that KPTI isn't that bad for performance and not Intel? I'd be curious to see that statement (not saying it isn't true).

In the long run, I guarantee that Intel/AMD/ARM/IBM/etc. are all going to have to make more fundamental hardware changes that at least mitigate these side-channel attacks. At least some of those measures may be performance-negative in nature but hopefully implementing them in hardware will be less of a hit than doing it all in software. If the side-channel attack is based at least in part on looking at timing differences for different sets of operations then two major ways to blunt the attack are to either force different operations to take the same amount of time or to introduce randomness into the timing of operations so that a side-channel attacker sees non-deterministic results. Either solution has drawbacks.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
derFunkenstein
Gold subscriber
Gerbil God
Posts: 24183
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 10:45 am

chuckula wrote:
AMD argues that KPTI isn't that bad for performance and not Intel? I'd be curious to see that statement (not saying it isn't true).


Uhhh...I think I've been misreading something all morning.

https://www.amd.com/en/corporate/speculative-execution

Variant 3 is meltdown, and AMD only says it's not affected. Variant 1 is where they expect a negligible performance hit and that's at least part of Spectre.

edit: from what you guys that are smarter than me have been saying int his thread and on the front page, it sounds like it'll be more than "negligible" impact on web browsers, and that would be pretty darn bad on mobile.
Last edited by derFunkenstein on Thu Jan 04, 2018 10:48 am, edited 1 time in total.
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
 
just brew it!
Gold subscriber
Administrator
Posts: 50699
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 10:47 am

chuckula wrote:
If the side-channel attack is based at least in part on looking at timing differences for different sets of operations then two major ways to blunt the attack are to either force different operations to take the same amount of time

Not feasible in the case of Spectre. The timing difference is based on whether a data item is in cache or not, so the only way to make them the same would be to artificially delay cached memory accesses to take as long as non-cached ones. IOW, you've just negated the whole point of having a cache in the first place.

chuckula wrote:
or to introduce randomness into the timing of operations so that a side-channel attacker sees non-deterministic results.

According to the paper, Chrome already does that. The researchers got around it by spawning a separate thread that just sits and spins, repeatedly altering the value of a shared memory location as fast as it can. This is sufficiently deterministic and high enough resolution to act as a timing reference, independent of the built-in timing mechanism that Chrome has intentionally made "sloppy" enough to foil timing analysis attacks.

chuckula wrote:
Either solution has drawbacks.

Well, I suppose you could say that. The first one would likely set us back 15 years in terms of CPU performance. The second one simply doesn't work, since it's already being done and the researchers who came up with Spectre figured out how to defeat it. Yes, you're technically correct, in that those are "drawbacks". :wink:
Nostalgia isn't what it used to be.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1679
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 10:56 am

just brew it! wrote:
chuckula wrote:
If the side-channel attack is based at least in part on looking at timing differences for different sets of operations then two major ways to blunt the attack are to either force different operations to take the same amount of time

Not feasible in the case of Spectre. The timing difference is based on whether a data item is in cache or not, so the only way to make them the same would be to artificially delay cached memory accesses to take as long as non-cached ones. IOW, you've just negated the whole point of having a cache in the first place.

chuckula wrote:
or to introduce randomness into the timing of operations so that a side-channel attacker sees non-deterministic results.

According to the paper, Chrome already does that. The researchers got around it by spawning a separate thread that just sits and spins, repeatedly altering the value of a shared memory location as fast as it can. This is sufficiently deterministic and high enough resolution to act as a timing reference, independent of the built-in timing mechanism that Chrome has intentionally made "sloppy" enough to foil timing analysis attacks.

chuckula wrote:
Either solution has drawbacks.

Well, I suppose you could say that. The first one would likely set us back 15 years in terms of CPU performance. The second one simply doesn't work, since it's already being done and the researchers who came up with Spectre figured out how to defeat it.


I definitely agree that the fixes will not be simple or good for performance.
Another idea that would hurt performance but could help mitigate these attacks: Cache flushes that clear out data from other userspace (or kernel space) code so that the only evictions from cache are from your own process context that you presumably can already read anyway. That way any set of cache evictions that are produced by branch mispredictions are evictions of data that are only in your own process. This would require pretty big changes to the shared caches that pretty much all CPUs use these days to be effective. Would this totally suck when doing lots of context switching? Absolutely, but hopefully there could be hardware techniques to mitigate the performance impact.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10725
Joined: Tue Aug 27, 2002 6:35 pm

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 10:58 am

JBI wrote:
Well, I suppose you could say that. The first one would likely set us back 15 years in terms of CPU performance. The second one simply doesn't work, since the researchers who came up with Spectre already figured out how to defeat it.


I think the biggest thing that Google did, which you already mentioned on the frontpage, is that site isolation thing. I was thinking when I read the spectre paper that chrome, thankfully, usually has multiple processes so it's a crapshoot what data from other sites a js attacker would be able to read, but that I also know that it often times aggregated multiple sites under a single process (at least that's what I remembered from shift+esc) rather often. That was obviously to keep the memory usage down, but it's now time for an absolute 1:1 relationship between site and Address Space: Chrome is going to be even *MORE* memory hungry.

So, as JBI said, enable site isolation everyone. Did Firefox finally finish e10s? Is it likewise forcible to 1:1? I use chrome and haven't really followed that for a year or more now.
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10725
Joined: Tue Aug 27, 2002 6:35 pm

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 11:00 am

chuckula wrote:
Another idea that would hurt performance but could help mitigate these attacks: Cache flushes that clear out data from other userspace (or kernel space) code so that the only evictions from cache are from your own process context that you presumably can already read anyway. That way any set of cache evictions that are produced by branch mispredictions are evictions of data that are only in your own process. This would require pretty big changes to the shared caches that pretty much all CPUs use these days to be effective. Would this totally suck when doing lots of context switching? Absolutely, but hopefully there could be hardware techniques to mitigate the performance impact


Spectre is reading from your own address space. This is still problematic: a Browser + JIT = I can use javascript to read all your passwords/tokens. Internal sandboxing does nothing.

Hence JBI's frontpage speculation about the new chrome 63 feature of site isolation: every site being its own process means every site has its own address space. It doesn't stop the attack, but it removes lucrative targets from being reachable with it.

EDIT: as JBI said and I alluded before, "fixing" javascript to make the exploit itself unfeasible means seriously, for real, breaking it: no more concurrent threads to avoid the shared memory + independent iterative addition = homebrew adequately precise timer, or getting rid of JIT so you can't just build the patterns yourself, other extremely bad performance-killing things, etc...
Last edited by Glorious on Thu Jan 04, 2018 11:06 am, edited 1 time in total.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1679
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 11:05 am

Glorious wrote:
chuckula wrote:
Another idea that would hurt performance but could help mitigate these attacks: Cache flushes that clear out data from other userspace (or kernel space) code so that the only evictions from cache are from your own process context that you presumably can already read anyway. That way any set of cache evictions that are produced by branch mispredictions are evictions of data that are only in your own process. This would require pretty big changes to the shared caches that pretty much all CPUs use these days to be effective. Would this totally suck when doing lots of context switching? Absolutely, but hopefully there could be hardware techniques to mitigate the performance impact


Spectre is reading from your own address space. This is still problematic: a Browser + JIT = I can use javascript to read all your passwords/tokens. Internal sandboxing does nothing.

Hence JBI's frontpage speculation about the new chrome 63 feature of site isolation: every site being its own process means every site has its own address space. It doesn't stop the attack, but it removes lucrative targets from being reachable with it.


OK, I was under the impression that Spectre's biggest trick was being able to read data from other processes. If you need to keep data secret within the context of a single process where you only partially trust the process then other isolation techniques for specific pieces of data that you really don't want leaked might be more useful.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
Ryu Connor
Gold subscriber
Global Moderator
Posts: 4283
Joined: Thu Dec 27, 2001 7:00 pm
Location: Marietta, GA
Contact:

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 11:14 am

https://support.microsoft.com/en-us/hel ... -kb4056891

Looks like the Microsoft Patch won't deploy unless your AV software is updated and adds a RegKey saying it's okay.

Due to an issue with some versions of Anti-Virus software, this fix is only being made applicable to the machines where the Anti virus ISV has updated the ALLOW REGKEY.
Contact your Anti-Virus AV to confirm that their software is compatible and have set the following  REGKEY on the machine
Key="HKEY_LOCAL_MACHINE"Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat"
Value Name="cadca5fe-87d3-4b96-b7fb-a231484277cc"
Type="REG_DWORD”
Data="0x00000000”


Edit:

https://support.microsoft.com/en-us/hel ... xecution-s

How to Enable/Disable KPTI on Windows Server.

https://support.microsoft.com/en-us/hel ... lative-exe

Guidance for Windows Client.

Looks like Microsoft is not enabling KPTI by default and leaving it in the hands of the Administrator to do so. There is apparently an expectation of firmware updates to go along side this patch.

Edit 2:

IE11 and Edge got some Spectre changes.

https://blogs.windows.com/msedgedev/201 ... 38B8w0c.97

Edit 3:

https://portal.msrc.microsoft.com/en-US ... /ADV180002

A broader breakdown from Microsoft. Looks like SQL server also is getting some guidance.
All of my written content here on TR does not represent or reflect the views of my employer or any reasonable human being. All content and actions are my own.
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10725
Joined: Tue Aug 27, 2002 6:35 pm

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 11:23 am

Ryu Connor wrote:
AV software


:Groan:

WILL NO ONE RID US OF THIS TURBULENT SOFTWARE?
 
derFunkenstein
Gold subscriber
Gerbil God
Posts: 24183
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Re: Intel Processor bug incoming?

Thu Jan 04, 2018 11:24 am

I don't get what media players have to do with it. Heyyyoooooo
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 8

Who is online

Users browsing this forum: No registered users and 1 guest