Live data from Hacker News

More Intel speculative execution vulnerabilities

mdsattacks.com

241–250 of 262 posts

Re: More Intel speculative execution vulnerabilities

#241

Earlier quoted context omitted.

It's mostly just that I'm afraid I'll order a board that isn't on the latest bios, which will be a headache. And an excuse to postpone.

Some MSI motherboards (and maybe others?) have a "Flashback" feature to flash BIOS from a USB storage device without needing a CPU.

Can confirm, mine supports this.

Re: More Intel speculative execution vulnerabilities

#242
I worked at Intel in 1998 as a young engineer a few years out of college. Back then they were riding high on their CPU monopoly.

I left in about a year and a half and moved to a startup company. My issue with Intel was that, as a monopoly, they had grown fat and complacent.

I am not exaggerating when I say that in 1998-99, engineers were working maybe 4-5 productive hours in a week. Political savvy and alliance-building were the most important things for promotions and influence.

Those who actually produced good work had credit for their work diluted through many layers of management. You could do something amazing and your manager's manager might present it in a powerpoint to the company without mentioning your name at all, and acting like the idea was his all along.

I'm surprised the company has lasted this long. Its a place where mediocre people gather.

Re: More Intel speculative execution vulnerabilities

#243
post #205

Earlier quoted context omitted.

> They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations. Given AMD's Zen 2 has comparable IPC to Intel at this point without doing the ACL check late it's not evident that the difference in when the ACL is done was a key efficiency gain.

I was not talking about intel's 10% lead over AMD, I was talking about chips from 3-4 years ago, when tested again now with mitigations, perform 10% worse or more in affected workload (see https://www.phoronix.com/scan.php?page=article&item=intel-ic... for exemple)

Surely the mitigations are not the same as "doing proper acl during speculation" in the first place and have a worse performance hit?

Re: More Intel speculative execution vulnerabilities

#244
post #118

Earlier quoted context omitted.

I'm 30+ years in. AMD shipped huge numbers of 8086/8088s as a second-source; you might have had one and not known it. But I'm guessing that's not what you mean. :-) There was a good bit of time where Opterons where everywhere on servers, including things like the whole Sun x86 line. At one gig we had datacenters full of IBM blade servers stuffed with dual Opteron boards; they were a big success in the market. I know…

I've heard that AMD suddenly pulling out of the server market was very damaging for the relationship with vendors, hence (in part) their trouble of getting back in the door . But it does seem that adoption is growing again, with recent performance figures and the attractive price point.

That's an interesting insight. Was it "pulled out" or "we screwed up the next gen product" though? Quite a gap between Opteron and Threadripper, so you're probably on to something.

Re: More Intel speculative execution vulnerabilities

#245

Earlier quoted context omitted.

Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything, just two or three additional unpatched PoCs with full source code would be enough. However, unlike buffer overflow exploits, most researches on CPUs are conducted within academic institutions, doing this certainly breaches the code of conduct. Also, CPUs are the most cr…

> Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything At the risk of sounding pedantic, that's not 'full disclosure', that's 'responsible disclosure' - https://en.wikipedia.org/wiki/Responsible_disclosure

Is it?

I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero is responsible disclosure because the information is released after the problem is patched. I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".

Re: More Intel speculative execution vulnerabilities

#246

Earlier quoted context omitted.

Selinux, apparmor, etc. are not viable security solutions for pretty much anything, because they are too coarse grained. Seccomp that blocks everything, but leaves just a couple of syscalls to interact with an external proxy process is closer to what could have worked, which is basically a sandbox.

How do you feel about openbsd's pledge()? I would really like something as simple as that on linux...

seccomp actually has that ability to allow only small portion of selective operations.

Block everything except io is just one of its blocking mode.

And the list is even configurable. Docker do use such ability to filter out sys-calls that shouldn't be used in the container.

Re: More Intel speculative execution vulnerabilities

#247
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 goi…

>BK was that the philosophy was "Focus on our key goals to the exclusion of everything else".

The Key Goals for the past 4 years if not longer were to ship 10nm with respectable yield. Which as closing of 2019 still didn't happen.

So I am not even sure what they were focused on.

Re: More Intel speculative execution vulnerabilities

#248
And yet, despite all of its security problems and issues with Intel, server vendors are buying more Intel than ever. On one hand they complain about Intel's pricing, threatening about making their CPU with POWER or ARM, on the other hand they happily use AMD as a tool to get better pricing.

The sales number dont lie, AMD doesn't even account for 10% of Server CPU shipment, and may not even happen in 2020 given Intel's new price cut.

Re: More Intel speculative execution vulnerabilities

#249

Earlier quoted context omitted.

It's mostly just that I'm afraid I'll order a board that isn't on the latest bios, which will be a headache. And an excuse to postpone.

Some MSI motherboards (and maybe others?) have a "Flashback" feature to flash BIOS from a USB storage device without needing a CPU.

Oh nice, I had no idea. I might pull the trigger on black friday then.
Post reply on HN