More Intel speculative execution vulnerabilities • Hacker News Board

Re: More Intel speculative execution vulnerabilities

#51

Post by IntelThrowaway » Wed, Nov 13, 2019, 9:28 AM UTC

Jonnax wrote: post #6

So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November. And they still didn't fix it. What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.

One of the problems with Intel culture - especially under BK was that the philosophy was "Focus on our key goals to the exclusion of everything else". It was meant to keep focus and ensure we moved quickly. The problem with that is it meant we were entirely unresponsive. It doesn't matter if something important has come up because you've already agreed what the priority is, you've already committed to what you're going to do. So even if something does come up, communicating that problem to the team that needs to fix it is impossible because you'll get ZBB'd (if we do this, we will drop that). Then once you've got engineering to commit, the bureaucracy won't let you just release anything so you need to line up into a release process.

I'm sure no one intended to mislead, but organisationally Intel just isn't designed to fix bugs. It doesn't have a process to respond to issues.

Re: More Intel speculative execution vulnerabilities

#52

Post by xucheng » Wed, Nov 13, 2019, 9:35 AM UTC

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, leaving the public with a false sense of security. Slapping a year-long embargo after another (many news cycles apart) and keeping vulnerabilities (too) many people are aware of from the public for a long time is still a viable strategy.

This is troubling.

Re: More Intel speculative execution vulnerabilities

#53

Post by yrro » Wed, Nov 13, 2019, 9:41 AM UTC

ageofwant wrote: post #10

Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off…

FYI, you can do the same thing with drop-in config files and avoid the annoying dpkg-conffile prompt whenever you upgrade grub2-common:

  $ cat /etc/default/grub.d/mitigations.cfg
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT mitigations=auto,nosmt"

Re: More Intel speculative execution vulnerabilities

#54

Post by systemcluster » Wed, Nov 13, 2019, 9:44 AM UTC

coldtea wrote: post #35

ageofwant wrote: post #10

Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off…

> No I don't give a fuck about the 'risk' this introduces Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...

Anecdotally, the performance hit from the security mitigations since the Spectre/Meltdown publication has been very noticeable.

Re: More Intel speculative execution vulnerabilities

#55

Post by wolf550e » Wed, Nov 13, 2019, 9:47 AM UTC

paulddraper wrote: post #29

wolf550e wrote: post #9

Earlier quoted context omitted.

AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.

AFAIK Spectre variant 1 only applies to a single address space; i.e. per process. Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.

There used to be a time when people thought relying on if statements for security was enough and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs. Now we know better.

1 - https://en.wikipedia.org/wiki/Singularity_(operating_system)

Re: More Intel speculative execution vulnerabilities

#56

Post by mywacaday » Wed, Nov 13, 2019, 9:55 AM UTC

the_duke wrote: post #39

krageon wrote: post #12

Earlier quoted context omitted.

Intel has become big and rich and has stopped (or perhaps never was) being very responsible. Given their fairly entrenched position in the industry, it's doubtful this strategy will impact their profit all that much and therefore we can expect to see more of this behaviour in the future.

Thankfully AMD is making serious headway and will continue to take market share from Intel. It will take time but Intel should begin to feel the sting soon.

I'm nearly 20 years in mid to large companies, I've never seen an AMD cpu on a desktop, laptop or server. Its almost like nobody ever gets fired for buying Intel.

Re: More Intel speculative execution vulnerabilities

#57

Post by [deleted] » Wed, Nov 13, 2019, 10:08 AM UTC

p_l wrote: post #24

wolf550e wrote: post #9

Earlier quoted context omitted.

AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.

> AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. > AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen. Putting memory permissions check in retirement stage of the pipeline could…

[deleted]

Re: More Intel speculative execution vulnerabilities

#58

Post by dijit » Wed, Nov 13, 2019, 10:21 AM UTC

scandinavian wrote: post #48

dijit wrote: post #41

Earlier quoted context omitted.

What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution. Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably…

From the comment in your link: > It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not. "analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers. Please feel free to link an example of one though, I will g…

The browser mitigation’s only work with the kernel mitigation’s. Neither is working well without the other. And yes. I’m very well versed on this topic.

Re: More Intel speculative execution vulnerabilities

#59

Post by [deleted] » Wed, Nov 13, 2019, 10:22 AM UTC

systemdtrigger wrote: post #30

rocqua wrote: post #26

Earlier quoted context omitted.

It can be used to defeat ASLR, which is a way to make exploiting code harder. However, defeating ASLR just makes it easier to deploy an exploit against a program, but you still need the exploit. It doesn't immediately give code exec, but generally it wouldn't be very hard to turn arbitrary memory read capabilities into privilege escalation. As long as you know what the system is running.

So the sense I'm making is- that most of thesr attacks need to be supervised and need you to be a target in particular?

[deleted]

Re: More Intel speculative execution vulnerabilities

#60

Post by mtgx » Wed, Nov 13, 2019, 10:25 AM UTC

xucheng wrote: post #52

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, l…

It certainly is, and that much was obvious as Intel "committed" to fixing Spectre V1 in software as opposed to hardware. Worse yet, it doesn't think a hardware solution is necessary. Except, that pretty much all recent Spectre-related bugs are variants of Spectre V1.