Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw • Hacker News Board

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

#471

Post by obscurantist » Wed, Jan 03, 2018, 10:01 PM UTC

rnhmjoj wrote: post #158

TheSwordsman wrote: post #132

I wonder what implications this will have on those who run Intel in their gaming rigs. I'm due to refresh, and _was_ gonna invest in Intel as my CPU. But this seems pretty damning for that. I assume the system calls to interact with the GPU, or to do any sort of I/O, are going to incur the performance overhead. So rendering frames, reading/writing from the network, and loading assets from the disk could all cause iss…

To make things worse there is an increasing number of games running DRMs like Denuvo and VMProtect that cause a significant performance hit. I think these will be more heavily affected by the patch.

I don't get why more developers don't take notes from CD Projekt.

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

#472

Post by stusmall » Wed, Jan 03, 2018, 10:11 PM UTC

throwaway613834 wrote: post #441

stusmall wrote: post #432

Earlier quoted context omitted.

Please just don't. It isn't worth the pain and risk just to have a little faster system. Maybe you don't care about this patch, but you will need others that are dependent on it. Just patch.

> Please just don't. It isn't worth the pain No, it very much is. > and risk No, there is no risk. I already run everything as admin. > just to have a little faster system. 5-30% is not "a little". > Maybe you don't care about this patch Indeed. And I expect many other power users also don't (but regardless, this is irrelevant). > but you will need others that are dependent on it. Well when that actually becomes a pr…

>Well when that actually becomes a problem I will act accordingly.

I don't mean to be rude but if you are having to ask how to disable automatic updates then you probably aren't someone who keeps up to date with all the latest issues. When it becomes problem, you just won't know.

Let your OS vendor do all this for you. They are good at it.

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

#473

Post by btilly » Wed, Jan 03, 2018, 10:17 PM UTC

viraptor wrote: post #439

btilly wrote: post #382

Earlier quoted context omitted.

Systems which both need lots of maxed-out CPUs and traffic directly from wild internet are pretty rare. That's a good description of basically every cloud environment out there, from AWS on down. In other words they are extremely common.

The CPUs in cloud environments are not maxed out in general. There will be some area like batch processing and compute-specific VMs. For other cases, there's quite a bit of overcommitting of resources. And that's before you start doing scheduling that mixed workloads on a physical host for better utilisation. Source: worked on a public cloud environment.

I agree with you on most VMs. But once you schedule mixed workloads, you want each host to be balanced so that all of its capacity is utilized evenly. Which means that if CPU use increases across the fleet, you will want new hardware with more CPU.

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

#474

Post by pkaye » Wed, Jan 03, 2018, 10:17 PM UTC

_0w8t wrote: post #210

spdy wrote: post #77

Earlier quoted context omitted.

Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our comp…

This implies that ARM vendors do less validation. I guess ARM is just so much simpler that good enough validation can be done faster. So essentially this is payback time for Intel for keeping compatibility with older code and simpler to program architecture (stricter cache coherence etc.). It is like one can only have 2 of cheap, reliable, easy-to-program.

I'm sure ARM vendors have their own problems... it is just that they tend to be used in application specific products so the bugs are worked around. Having come from a firmware background I've worked are tons of ugly workarounds for serious bugs in validated hardware.

Furthermore, I just a read an article (can't find the link) that certain ARM Cortex cores have this same issues as Intel.

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

#475

Post by Pharaoh2 » Wed, Jan 03, 2018, 10:18 PM UTC

throwaway613834 wrote: post #467

Pharaoh2 wrote: post #416

Earlier quoted context omitted.

I can think of a few ways to get privilege escalation if you already have rce as unprivileged user: 1. Read the root ssh private key from the openssh deamons kernel pages maintaining the crypto context and ssh into the system 2. Read a sudo auth key generated for someone using sudo and then use that to run code as a root user 3. Read the users password's whenever a session manager asks the users to reauth 4. If runni…

Thanks! I see. So it seems like the program basically has to capture sensitive data while it is in I/O transfer (and hence in kernel memory) just at the right time, right? Which is annoying and might need a bit of luck, but still possible. Incidentally, this seems to indicate that zero-copy I/O is actually a security improvement as well, not just a performance improvement?

4,5 and 6 don't need to time the attack.

I am not really sure how/if zero copy may/may not solve this problem.

If this bug only allows reading kernel pages, zero copy may actually help if the unprivileged user can't read your pages, but from the small amount of available description it looks like it can read any page, but kernel pages are more interesting because thats a ring lower and which is why all the focus is on that.

I am fairly certain there is more protection against being able to read memory owned by process on a lower ring level so zero copy may be a bad idea for security critical data.

And based on the disclosure that google published, looks like any memory can be read

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

#476

Post by shaki-dora » Wed, Jan 03, 2018, 10:23 PM UTC

GVIrish wrote: post #447

matt4077 wrote: post #420

Earlier quoted context omitted.

Don't spread conspiracy theories. It's absolutely impossible for the most visible executive of one of the largest firms to engage in insider trading in such an obvious fashion and get away with it. At this level, there is always a paper trail of who knew what when. There are internal and external audits if any suspicions arise. Plus there are sever penalties, both civil (in the employment contract) as well as crimina…

I think we're going to find in the coming years that there is a lot of white collar crime going on at any time. It seems like it would be foolhardy to attempt this stuff, but greed compels people to do stupid things all the time. Wealthy C-suite people are not totally immune to that.

You'll be happy to know that:

[in 2016] the FEC Charged 78 parties in cases involving trading on the basis of inside information.

A number of these cases involved complex insider trading rings which were cracked by Enforcement’s innovative uses of data and analytics to spot suspicious trading.

For example, brought insider trading cases against:

- two hedge fund managers and their source, who was a former employee of the U.S. Food and Drug Administration

- a former Goldman Sachs employee

- a former senior employee at Puma Biotechnology Inc.

https://www.sec.gov/news/pressrelease/2016-212.html

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

#477

Post by exabrial » Wed, Jan 03, 2018, 10:27 PM UTC

pkaye wrote: post #469

rbanffy wrote: post #427

Earlier quoted context omitted.

We'll start being more syscall conscious when we write our programs. We'll batch more at the user mode side and try to use less syscalls to do the job. Kernel ABIs will eventually reflect that and crop up higher level expensive calls that replace groups of currently cheap syscalls (that will become expensive after the fix). And Intel will profit handsomely from next generation CPUs that'll get an instant up-to-30% pe…

What about all the kernel interrupts due to network and storage traffic?

Maybe the scheduler could dedicate a core to interrupts and software that has small quanta and page tables? Can't really think of a code solution that doesn't sound stupid when I type it.

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

#478

Post by exabrial » Wed, Jan 03, 2018, 10:28 PM UTC

qubex wrote: post #464

exabrial wrote: post #315

Earlier quoted context omitted.

Yep, I'm still wondering how this affects ARM and if it can be corrected in microcode on that platform. I'm also wondering if/hoping for a fix that involves increased memory usage instead of the speed.

I’m not a very proficient programmer/developer, so please bear with me. I’m intrigued by your reference to trading off greater memory footprint in exchange for diminishing performance by less. I'm trying to understand how this would work in practice: do you envision ‘padding’ the critical data structures with more empty or randomised buffer zones? Wouldn't that incur an additional penalty for the data transfer (Von N…

Oh I have no idea actually; it's just pretty normal to see a speed-memory trade in a lot of problems. I'm definitely not low-level enough either.

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

#479

Post by throwaway613834 » Wed, Jan 03, 2018, 10:31 PM UTC

stusmall wrote: post #472

throwaway613834 wrote: post #441

Earlier quoted context omitted.

> Please just don't. It isn't worth the pain No, it very much is. > and risk No, there is no risk. I already run everything as admin. > just to have a little faster system. 5-30% is not "a little". > Maybe you don't care about this patch Indeed. And I expect many other power users also don't (but regardless, this is irrelevant). > but you will need others that are dependent on it. Well when that actually becomes a pr…

>Well when that actually becomes a problem I will act accordingly. I don't mean to be rude but if you are having to ask how to disable automatic updates then you probably aren't someone who keeps up to date with all the latest issues. When it becomes problem, you just won't know. Let your OS vendor do all this for you. They are good at it.

> I don't mean to be rude but if you are having to ask how to disable automatic updates then you probably aren't someone who keeps up to date with all the latest issues. When it becomes problem, you just won't know.

...Wow. First of all, that's not what I asked. I asked how to disable or block this patch. Blocking "automatic updates" is neither equivalent to disabling this patch (post-install) nor to blocking it (pre-install). Second of all, I'm running Windows 8.1, on which I can actually block updates easily. I don't know if I can be picky about which patches I block on 10 because I have barely used it, but I will have to start using it soon and I really don't want to waste time installing the update only to find out I can no longer uninstall it.

And third of all, you're really spewing nonsense. I've done security work in the past which I don't care to post details about here anonymously. I still keep up with security news regularly and I actually look into the update details before installing them (which should be obvious if you read my previous comment on how I said what I do depends on the actual updates). None of which you need to believe (and I really don't care if you don't), except for the minor caveat that if you're trying to be convincing, this holier-than-thou attitude moves you well in the opposite direction.

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

#480

Post by lttlrck » Wed, Jan 03, 2018, 10:33 PM UTC

RobAtticus wrote: post #456

Houshalter wrote: post #444

Earlier quoted context omitted.

A CPU from 2017 is going to run your programs a hell of a lot faster than one from 2003. Even if they technically have the same clock speed. Look at benchmarks for instance: https://www.cpubenchmark.net/high_end_cpus.html

The claim wasn't "CPUs in 2017 are not faster than CPUs in 2003" or even "CPUs in 2017 are not much faster than CPUs in 2003"; the claim was that they haven't followed Moore's law since 2003, so applying it to CPU speed nowadays is inaccurate. Of course CPUs are faster now than they were 14 years ago, just not as fast as the case where Moore's law still applied to CPU speed.

Moore’s Law doesn’t describe CPU clock speed increases.