Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

bloomberg.com

Post reply on HN
Print view View original

331–340 of 567 posts

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#331

Post by uniformlyrandom »

rwmj wrote: post #5

AMD must be pretty happy about this patch: https://lkml.org/lkml/2017/12/27/2

Not so sure about that. I am reading the merge commit, and comments are pretty interesting:

  --- a/arch/x86/include/asm/processor.h  
  +++ b/arch/x86/include/asm/processor.h
  + * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
  + * address, then that syscall will enter the kernel with a
  + * non-canonical return address, and SYSRET will explode dangerously.
  + * We avoid this particular problem by preventing anything executable  
  + * from being mapped at the maximum canonical address.
  + *
  + * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
  + * CPUs malfunction if they execute code from the highest canonical page.
  + * They'll speculate right off the end of the canonical space, and
  + * bad things happen.  This is worked around in the same way as the
  + * Intel problem.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#332

Post by rdtsc »

jcadam wrote: post #154
rdtsc wrote: post #112

Earlier quoted context omitted.

The privilege escalation is being fixed in software. The problem is that mitigation involves patching the kernel and that patch results in around 30% slowdown for some applications like databases or anything that does a lot of IO (disk and network). That's the big deal. Imagine you are running at close to full capacity after security fix reboot your service might tip over. It could mean a direct impact to cost and so…

Oh good, I put my SaaS (running mostly on Linode) up yesterday, then this happens. Can't wait for Linode to apply this patch to their infrastructure :( I'm cursed when it comes to timing. It's like when I bought that house in 2007, held onto it waiting for the market to recover, then tried to sell it only to find out my tenants had been using it to operate a rabbit-breeding business for years and completely trashed t…

> Also, I hate rabbits now. And I veered off topic, sorry.

Well I guess you're not the right person to without about a great ninja-rockstar position at our new RaaS startup.

/one has to joke sometimes to avoid crying over taking a 30% hit in costs... over a stupid CPU bug

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#333

Post by bogomipz »

theoh wrote: post #326
bogomipz wrote: post #309

Earlier quoted context omitted.

>"It's a good thing CPU is fairly compressible." What do you mean by "compressible"?

Presumably, for a certain important class of application, CPU is not used "densely", i.e. continually. Instead it's used intermittently, like a gas rather than a solid... Hence compressibility. Such applications are far from being CPU-bound, in other words.

So a cloud provider would be an example. Compressible similar to a sparse file I guess as well. Thanks this makes sense.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#334

Post by throwaway613834 »

uniformlyrandom wrote: post #319
throwaway613834 wrote: post #253

Will there be any way to disable or block the upcoming patches and keep the performance for those of us who really just don't have any reason to care about inter-process information leakage on our personal computers? Edit: I'm (also) wondering about Windows, in case anyone knows yet.

From the merge commit: +#ifdef CONFIG_PAGE_TABLE_ISOLATION +# define DISABLE_PTI 0 +#else +# define DISABLE_PTI (1 PS - MSFT has not published relnotes, so we do not know yet. We'll find out soon enough.

I meant disable at run time, not disabling via recompiling your own kernel.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#335

Post by blattimwind »

cypherpunks01 wrote: post #308
blattimwind wrote: post #55

Earlier quoted context omitted.

https://twitter.com/brainsmoke/status/948561799875502080

What does that output mean? He was able to look up an address that was used in a speculative execution or something?

He successfully read from kernel memory, the first two bytes from the syscall table to be precise. The first entry is sys_read (on x86-64 anyway) and the first field is the address. That's why he shows the full address in the next line; the PoC exploit read the lower 2 bytes of that address.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#336

Post by pixl97 »

cesarb wrote: post #35

This article appears to be jumping the gun. It presents the defect as a fact, but aren't we still in the "rumor" phase (other than perhaps the few who have early access to embargoed details)?

https://twitter.com/brainsmoke/status/948561799875502080

Doesn't seem to be much of a rumor.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#337

Post by dingo_bat »

chrisper wrote: post #180

If you look here: https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheit... (Sorry it is German) But if you scroll down to "Windows-Benchmarks: Anwendungen" you can see that most applications do not have any performance hit with the Windows patch. Only M.2 SSD seem to be affected.

It is possible Microsoft has mitigated the issue in a way that has much lesser performance impact. Maybe they had a highly tuned feature to enable kernel page separation already coded but disabled. I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#338

Post by yeukhon »

DannyB2 wrote: post #72
rayiner wrote: post #52

Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege esca…

There is this thing called "return oriented programming". You write your program as a series of addresses that are smashed onto the stack through some other type of vulnerability. When the current function returns, it returns to an address of your choosing. That address points to the tail end of some known existing function, such as in the C library and other libraries. When the tail end of that function returns, it…

> If you could know all of the addresses of important kernel routines

Are those kernel logical addresses?

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#339

Post by bartread »

elFarto wrote: post #298
josefx wrote: post #276

Earlier quoted context omitted.

Right now I am just hoping that it wont add significant overhead to OpenGL. My application already has a bottleneck on changing OpenGL states and issuing render commands and I have no idea how much of that time is spend making syscalls.

OpenGL implementations shouldn't be effected by syscall overhead. Historically it's been DirectX that had a syscall per draw call, but I believe both now just write the command to GPU RAM directly.

That's at least somewhat encouraging. Nevertheless, it sounds rather like the old, "Yes, but will it run Crysis?" question will perhaps have renewed relevance.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#340

Post by AnimalMuppet »

ianai wrote: post #174
golfer wrote: post #168

Earlier quoted context omitted.

Anyone can sue anyone else at any time. If you think Intel isn't going to be sued for this, you're wrong.

They need some legal standing or the case can be dismissed out of hand. It may very well be a question of who has the better legal team.

> They need some legal standing or the case can be dismissed out of hand.

Yes and no. Yes, Intel would get a chance to claim that the case should be dismissed out of hand. To do that, they have to prove that, even assuming all the claimed facts are true, the people suing still don't have a valid case. That's a high bar. It can be reached - there's a reason that preliminary summary judgment is a thing in court cases - but it takes a really flawed case to be dismissed in this way.

How flawed? SCO v. IBM was not completely dismissed on preliminary summary judgment, and that was the most flawed case I've ever seen.

> It may very well be a question of who has the better legal team.

Well, Intel can afford to hire the best. A huge class-action suit can sometimes attract the best to the other side as well, though. (There's not just one "best", so there's enough for both sides of the same court case.)

IANAL, but it looks to me like there's at least the potential for a valid court case. CPUs are (approximately) priced according to their ability to handle workloads; if they can't provide the advertised performance, they didn't deserve the price they sold for.

Post reply on HN