Hacker News Reader

Comment by kardos | Hacker News Reader

On one hand, great news for Intel: everyone needs a new chip. On the other, terrible news for Intel: AMD's offerings are pretty competitive these days. It'll be interesting to see how this plays out.

View on HN

Meltdown: affects only Intel CPUs, is the 'biggy' short-term, but patches to mitigate it are landing as we speak and patches to eliminate it using trampolines are described in the paper. So no need to replace your Intel CPUs unless you can't live with the performance drop, but a good reason for buying AMD going forward.

Spectre: hits AMD too. Hits everyone today. Hope for a new arch (bias: I am a Mill CPU dev ;) )

> bias: I am a Mill CPU dev

This has been in the back of my mind during all of this.

Can you [0] outline to what extent Mill would or would not be affected by both Spectre and Meltdown?

[0] or is anyone from Mill planning to

personally I'm thinking about buying some GreenArray 144 forth cpu

We are immune. Give us a day or two to do a proper assessment and write it up.

Very much looking forward to this!

Where and when can I buy a Mill CPU? This has been name-dropped in a few threads but best sources say it's been "in development" since 2003 which sounds like vaporware to me.

Mill feels like the GNU Hurd of CPUs.

Hurd on Mill is the Hurd on Mill of... oh wait...

It only exists on paper.

Is Mill ever going to come out with real hardware that "normal" people can use? Or is it just an R&D project, and focused on selling the IP?

Can't it be fixed with a microcode update?

nope.

Why not? What can?

It's very likely that because this is a performance driven optimization that exposes the security hole it is at a layer beneath the microcode from how the instruction pipeline/branch prediction was working to begin with. The wiki page for Instruction Pipelining is pretty good https://en.wikipedia.org/wiki/Instruction_pipelining. There was already problems in multicore systems for false sharing/other cache issues. As far as my understanding goes microcode is only useful for the logical wiring of the various subsystems of the CPU together to perform the requested operation, but it is not generally 'inside' the actual operations (ex: at a certain point shift left one bit turns into currents through gates, and there's no microcode at that level). If you bring it to a higher level of abstraction on a particular motherboard you might be able to flash the firmware of the BIOS, and the memory controller has a known issue you may be able to use the BIOS to access it differently but for a certain class of issues if you can't change how you signal the memory controller to work around it and the memory controller is not a replaceable part you might be screwed and need a new motherboard that just doesn't have the issue which seems to be closer to what we have here.

That is why there is a big fuss about it

maybe future processors will have more microcode for other subsystem ..

The low hanging fruit to mitigate Spectre would be to flush cache lines which were touched by false-speculation branch executions. Of course there'd be possible interaction with other, truly executed code hitting the same cache line.

Iff the microcode had instructions for cache line state manipulation it would be possible to emit µOps flushing cache lines touched in the other branch when merging with the true branch.

However this mitigation would only be possible if there were µOps for doing that and the instruction decoder was powerfull enough to do this kind of thing. Eventually we'll likely see silicon in which cache lines get additional status bits that keep track by which OOE engine the data was fetched and after branch merging flush all cache lines not matching the taken branch.

I'm not sure that'd help - as someone else observed in another thread, loading anything into a cache requires evicting something else, and that eviction can be measured. You could do something like maintaining a full duplicate of the cache and tracking deltas, but I feel like that's back in "rearchitect the CPU from the ground up" territory.

Do Intel even sell any non-vulnerable CPUs?

I'm guessing Itanium is not vulnerable.

First couple of generations of Atoms, before they went out-of-order.

Maybe they have some surplus 8085s from a trade-in program?

[I remember hearing about an engineer for railway signaling systems buying up all the 8085s he could get to use in new systems, because that was the last CPU where he felt confident he understood all the bugs. Alas, I can't find a reference any longer]

Reply on news.ycombinator.com