Intel Unveils New Coffee Lake 8th Gen Core Line-Up With First Core i9 Mobile CPU (hothardware.com)

MojoKid writes: Intel is announcing a big update to its processor families today, with new 8th Gen Coffee Lake-based Core chips for both mobile and desktop platforms. On the mobile side of the equation, the most interesting processors are no doubt Intel's new six-core Coffee Lake parts, starting with the Core i7-8750H. This processor comes with base/max single-core turbo boost clocks of 2.2GHz and 4.2GHz respectively, while the Core i7-8850H bumps those clocks to 2.6GHz and 4.3GHz respectively. Both processors have six cores (12 threads), a TDP of 45 watts and 9MB of shared Smart Cache.However, the new flagship processor is without question the Intel Core i9-8950HK, which is the first Core i9-branded mobile processor. It retains the 6/12 (core/thread) count of the lower-end parts, but features base and turbo clocks of 2.9GHz and 4.8GHz respectively. The chip also comes unlocked since it caters to gaming enthusiasts and bumps the amount of Smart Cache to 12MB. Intel is also announcing a number of lower powered Coffee Lake-U series chips for thin and light notebooks, some of which have on board Iris Plus integrated graphics with 128MB of on-chip eDRAM, along with some lower powered six-core and quad-core desktop chips that support the company's Optane memory in Intel's new 300 series chipset platform.

Comments

Meltdown and Spectre compatible?

[Anonymous Coward]

I am curious if these chips will break compatibility with the previous Meltdown and Spectre data sharing apps. Have they made changes to this feature set?

Re:Meltdown and Spectre compatible?

[tigersha]

The coffee lake was caused by a Meltdown of a valve in the Santa Clara Starbucks, so no, I suspect not.

Have they fixed Meltdown and Spectre?

[Anonymous Coward]

So do these new chips have Meltdown and Spectre hardware fixes?

Re:Have they fixed Meltdown and Spectre?

[Anonymous Coward]

No. Only workarounds in microcode that reduce performance.

Re:Have they fixed Meltdown and Spectre?

[93 Escort Wagon]

No. Only workarounds in microcode that reduce performance.

They also contain Intel's patented Deflect-Towards-AMD technology.

Re:Have they fixed Meltdown and Spectre?

[Billly Gates]

No. Only workarounds in microcode that reduce performance.

Neither. Branch prediction is so Central to the CPU architecture that it can't be disabled. MS is working on it's compiler to see if can do special assembly tricks to hide the cache.

Linux has kernel hacks which attempt to hide the data from the cache which hackers can still overide with skill

Re:Have they fixed Meltdown and Spectre?

[TheRaven64]

Meltdown allows you to use timing attacks to snoop data across a system call. This is because Intel used an optimisation where they treated system calls as branches, whereas on AMD chips they resulted in a pipeline stall. The Spectre vulnerabilities work at the same hardware privilege level, though not necessarily at the same software privilege level (for example, you can read past a bounds check in a NaCl or JavaScript sandbox and read memory outside of the sandbox, which gives you the memory disclosure vulnerability that you need to launch a code reuse attack).

The defence against Meltdown is to unmap kernel memory when in userspace. This means that the CPU would have to speculate past the CR3 update (switch page tables to the userspace mappings) to be vulnerable. Current CPUs don't do that, because it's really hard to do: You need to be able to invalidate TLB fills, because the page tables that you've installed might be wrong. TLB fills as a result of normal speculative execution are fine, because the TLB is always an arbitrary subset of the contents of the page tables, so you don't need to invalidate them. Sometimes this can even give a big performance boost. Apple found a few years ago that they were getting a big speedup because a mispredicted branch was prefetching some data into the cache that they were using later. The mispredicted branch was much cheaper than stalling for the cache fill. In hindsight, I should have realised that Spectre-like attacks were possible when I learned about this.

The defence against the Spectre variant 1 attack is to add a data dependency where previously there was a control dependency. For example, if you have some code that looks roughly like this pseudocode:

if (bounds_check(address, offset))
{
load(address + offset);
}

You turn it into something like:

check = bounds_check(address, offset);
if (check)
{
load(select(check, address + offset, 0));
}

Where the select becomes a conditional move instruction (or some equivalent arithmetic operation). This transformation means that the load now has a data dependency on the result of the bounds check and so won't be dispatched until the bounds check has been calculated. This, in turn, means that there won't be any observable side effects of the load if the branch would not be taken because the instructions inside the conditional will be canceled as soon as the branch is determined to be not taken. This probably has a small performance overhead, because it will introduce pipeline bubbles. I'd be surprised if it were more than 5% though.

Variant 2 involves poisoning the branch target buffer so that at a specific point in execution the CPU will predict a jump to attacker-controlled code. You can then put timing sensitive instructions at that point and probe register values. The mitigation for this is called a retpoline, where you perform an indirect branch using a return instruction, which then uses the return buffer for prediction and so will predict the address after the last call. This basically forces a branch mispredict, but to a location that isn't controlled by the attacker.

Some of the proposed hardware fixes involve not sharing branch predictor state across security contexts. This is not ideal, because often that sharing is beneficial. For example, if you an Android app, it's forked from a zyogte process that sets up the VM and pre-loads a bunch of classes. All apps will have the same core system code in the same addresses and can benefit from sharing branch predictor state. Similarly, if you run a server in a pre-fork model.

New CPUs come in so they refuse to fix Spectre

[Anonymous Coward]

In the meantime they have posted that there will be *NO* microcode updates for the older generations as stated in https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf (serach for "stopped").

There are software workarounds, but well... still leaves a bad taste considering they originally wanted to develop new microcode for those generations.

Re:New CPUs come in so they refuse to fix Spectre

[thegarbz]

Given their previous microcode rollouts I think we can all collectively sigh with relief.

Why bother?

[Anonymous Coward]

It's all window dressing. This is about as exciting as the difference between a 2017 Hyundai Elantra and and 2018 Hyundai Elantra. We are approaching almost a decade since Intel offered anything significantly different or improved.

Re:Why bother?

[sinij]

Digital computing is reaching a dead end now.

Not until Netcraft confirms it.

I wonder...

[WolfgangVL]

Every time I see the word "unveil", I first wonder, how long was it veiled to begin with? Then I wonder, how many more iterations are still "veiled", awaiting the perfect time to "unveil", so as to maximize profits?

I imagine a bunch of marble pedestals with thin white sheets over them, each with red LCD displays counting down...... every now and then an alarm goes off and the room full of monkeys next door starts typing till they come up with a name......

same pci lanes bottleneck

[eaglesrule]

16 pci-e lanes ought to be enough for everyone.

Re:Obligatory silly name joke

[chmod a x mojo]

It's been out for decades! Just put your perc pot over the molten hole where your Prescott processor used to be before it melted through the motherboard, floor, and planets core. You should have a fresh pot in no time at all.