'Kernel memory leaking' Intel processor -- a serious cpu bug!?!

[rsmus7]

read here:

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/
and
http://pythonsweetness.tumblr.com/post/ ... page-table


I'm really curious what that means to the DAW benchmarks,
will the intel cpus be much slower than AMD after a fix?

[BertKoor]

That depends on how much data transfer between kernel and user memory space is needed.
You'll have to wait for the patch and updated benchmark results

[planetearth]

Looks like it's going to be pretty serious, yes. But since Intel's sitting on the details, we won't know until the OS updates roll out. And even then, you may not know exactly how much of a "hit" your system will take unless you do some before-and-after benchmarks yourself. Someone may publish some average performance drops for i3, i5 or i7 chips, but I doubt anyone will test and publish results for all the processor's Intel's released over the past decade (which is how long this has been a problem, according to the article).

Steve

[jdnz]

Looks like it's going to be pretty serious, yes. But since Intel's sitting on the details, we won't know until the OS updates roll out. And even then, you may not know exactly how much of a "hit" your system will take unless you do some before-and-after benchmarks yourself. Someone may publish some average performance drops for i3, i5 or i7 chips, but I doubt anyone will test and publish results for all the processor's Intel's released over the past decade (which is how long this has been a problem, according to the article).

also the slowdown will depend massively on the workload - things that are i/o intensive (so stuff like database servers) or running virtualisation will suffer the most - so you can see why it’s going to be a massive deal to the big cloud providers. On a single user system I’d expect the slowdown to be at the low end of the ranges suggested.

still trying to find exactly when intel implemented process context identifiers (PCIDs)

[jdnz]

right - if you download 'coreinfo' from microsoft sysinternals (https://docs.microsoft.com/en-us/sysint ... s/coreinfo) and run it amongst the copious amounts of info it spews out is whether your CPU supports PCIDs

I just ran it on an i7-4770 and sure enough it DOES support PCIDs, so when the article on the registers says 'the PCID features on recent intel cpu's will mitigate the impact of KPTI' they were obviously using 'recent' only in relative terms.

[aciddose]

The real concern isn't the performance penalty: for single users systems quite frankly you don't need to give a shit. If you run "bad" software on the system you're toast either way. Whether due to this problem (very unlikely) or other privilege escalation issues (very likely).

The real issue is for large data centers. Think about google, or the NSA, CIA and so on. Large banks and corporations. Apple uses private keys to provide encryption for all iOS devices, Sony has sets of private keys in a tree where the highest level keys could significantly defeat the entire protection on their blu-ray devices. (Although most likely such keys are locked in some uber-vault never to see the light of day, possibly written in black marker on the CEO's liver.)

If these systems are running Intel CPUs it means the security of the system is essentially zero in the case "bad software" is running at a lower privilege level on those systems. The details of exactly how much effort it takes to gain access to private keys in kernel space and therefore access everything encoded with that key on every system ever (communications between spies?) is the real issue.

It doesn't really even matter how hard it is, if it's possible rather than impossible you should expect anyone concerned with security to have already taken these systems offline and be near heart-attack in trying to figure out if there is any way to identify whether they've had private keys stolen because of it.

For anyone not protecting confidential information on "cloud" servers with 1000s of users (Amazon, etc) the solution is simply to not install the patch, or only install a patch that can also be disabled at will where performance issues are a concern.

Not really an issue for DAWs.

Details about what is actually at risk are due to come out within weeks. There has been speculation that javascript code could lead to exploitation of this bug in browsers... but my opinion about that is it seems damn near zero chance that is true. Perhaps if you have "webassembly" but I still don't think it's very likely. I wouldn't believe such speculation until real information comes out to prove it.

So at this point you don't even need to patch your DAW or give 1/2 a shit.

[sprnva]

I ran the Intel tool that checks for the vulnerability and it said that none of my machines here are affected.

Hopefully any fixes that might bring slowdowns won't do so on chips that are not vulnerable.

[Daags]

I ran the Intel tool that checks for the vulnerability and it said that none of my machines here are affected.

hey buddy, that's swell. you know what would really help ? if you specified what chipset your various machines are running. thanks

[ghettosynth]

I ran the Intel tool that checks for the vulnerability and it said that none of my machines here are affected.

hey buddy, that's swell. you know what would really help ? if you specified what chipset your various machines are running. thanks

Is there a link for this "tool?"

On Edit:

https://downloadcenter.intel.com/download/27150

[cron]

AFAIK that's an unrelated vulnerability that can be addressed with a firmware update. We're looking at something entirely new here that requires OS level patching.

Carried over from the other thread, Intel's CEO sold all his stock in mid-December and now owns the minimum allowable number of shares. A sign of things to come? https://www.fool.com/investing/2017/12/ ... stock.aspx

[ghettosynth]

Ok, so based on that tool and running sysinfo, my almost ancient i5-2500k is not vulnerable, supports PCID, but does not support INVPCID. I don't know enough about modern processor architecture to say anything significant about what that means.

Based on that I'm not sure that this will effect too many people using DAWs. Sandy Bridge came out in 2011 and ATM that's the oldest machine that I have running. It might be fun to start up an older core 2 machine, but I suspect that we have a few KVR luddites that will beat me to it

[ghettosynth]

AFAIK that's an unrelated vulnerability that can be addressed with a firmware update. We're looking at something entirely new here that requires OS level patching.

Carried over from the other thread, Intel's CEO sold all his stock in mid-December and now owns the minimum allowable number of shares. A sign of things to come? https://www.fool.com/investing/2017/12/ ... stock.aspx

Fair enough, I didn't look closely, it was the only tool linked in an article. Is there a different tool, or, was that the tool that the parent was referring to?

[ghettosynth]

From:

https://hothardware.com/news/intel-cpu- ... dows-macos

If the reports are accurate, it appears that Intel might have a pretty severe chip-level security bug on its hands that cannot be simply swatted away with a microcode update. The bug affects all modern Intel processors dating back at least a decade.

Also, while the bug does not affect AMD chips, the current linux patch is applied to all x86 chips leading to a performance decrease there as well.

[cron]

I'm wondering it's even possible to release a tool until the embargo on the exploit lifts and the patches are available. They wouldn't even tell us what they're actually testing for at the moment.

[gentleclockdivider]

Does this affect all intel cpu's , or only the latest generation ?
Was planning to update my whole system , but this is seriously bad news .
Might go the amd route now

edit : we're talking about cpu's made in the last decade .