Intel CPU Design Flaw / Meltdown Attack - implications for Real Time audio

[gimmeapill]

Hopefully, given the amount of heat they take, Intel will fix their game...

Sure they will, around 2021 we have new shiny working CPUs.

That's harsh
Now that the fire is lit, I would expect a redesigned chips for next fall/christmas, and hopefully some systems without this IME/AMT junk (no offense to Minix though).

But yeah, Linux on arm has suddenly become more interesting

[tavasti]

Hopefully, given the amount of heat they take, Intel will fix their game...

Sure they will, around 2021 we have new shiny working CPUs.

That's harsh
Now that the fire is lit, I would expect a redesigned chips for next fall/christmas, and hopefully some systems without this IME/AMT junk (no offense to Minix though).

See https://twitter.com/securelyfitz/status ... 0652196864 for schedules.

[Lyberta]

Chips without IME? Ask China to design their own chips so they will have Chinese backdoors in them. Now, you will be safe from NSA

[gimmeapill]

Chips without IME? Ask China to design their own chips so they will have Chinese backdoors in them. Now, you will be safe from NSA

System76 managed to disable most parts of IME on some of their existing systems, so that doesn't sound like an outlandish requirement:
http://blog.system76.com/post/168050597 ... dates-plan

Still, for Intel to actually put their money where their mouth is, I think it would take yet another widespread scandal....

[tavasti]

System76 managed to disable most parts of IME on some of their existing systems, so that doesn't sound like an outlandish requirement:
http://blog.system76.com/post/168050597 ... dates-plan

And when Intel makes new processors with meltdown and spectre problems fixed, they will also find something to protect IME better from removal.
99% of customers don't care, so they can continue spying us.

[tramp]

And when Intel makes new processors with meltdown and spectre problems fixed, they will also find something to protect IME better from removal.
99% of customers don't care, so they can continue spying us.

Exactly why I mention ME here, as, what is it worse to fix the meltdown and spectre issue, and risk your latency, while you've a spy engine deep in your CPU?

[gimmeapill]

Code: Select all

Exactly why I mention ME here, as, what is it worse to fix the meltdown and spectre issue, and risk your latency, while you've a spy engine deep in your CPU?

Because they are not exploitable by the same bad guys (or at least that we know so far)?

[tramp]

Because they are not exploitable by the same bad guys (or at least that we know so far)?

Hmm, first, the question is whom do you call to the "bad guy's" and later, as a fact, the attacks against port 16992 and 16993 been exploded since then.

[gimmeapill]

Because they are not exploitable by the same bad guys (or at least that we know so far)?

Hmm, first, the question is whom do you call to the "bad guy's" and later, as a fact, the attacks against port 16992 and 16993 been exploded since then.

To quote the Register, the world of bad guys divides between the "Spooks" and the "Crooks".
Protecting against the crooks already goes a long way - and this is the only sensible thing to do in the long run.
Protecting against the second kind has historically proven more tricky. ex: If you want to be protected from firmware level exploits, well, you should probably avoid most consumer grade hardware and operating systems in the first place.
And assuming this is even practically possible, you're probably not going to have a very enjoyable multimedia experience...

So, no matter how hard to swallow are the Meltdown and Spectre patches, there seems to be (for once) a consensus across the whole industry - everyone should get them, happy or not.

You can always choose tho disable completely or cherry pick in case of a proven performance impact.
There's a very good whitepaper by Red Hat in case anyone missed it:

Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables: https://access.redhat.com/articles/3311301

Regarding port scanning on 16992 and 16993: you don't open those to the outside, do you?
So this is pretty much business as usual so far.
Things might however become hairy if OS level exploits against IME show up - but that is unfortunately the kind of exposure needed to have Intel actually take action...