Meltdown/Spectre week three: World still knee-deep in something nasty

It is now almost three weeks since The Register revealed the chip design flaws that Google later confirmed and the world still awaits certainty about what it will take to get over the silicon slip-ups. The short version: on balance, some steps forward have been taken but last week didn't offer many useful advances. In the " …

[Anonymous Coward]

Had to disable Spectre mitigation

Since patching my Office HP ProDesk PC with MS and BIOS updates, it was constantly logging this event:

Event 19 Source WHEA-Logger

A corrected hardware error has occurred.

Reported by component: Processor Core

Error Source: Corrected Machine Check

Error Type: Internal parity error

It has also had 6 BSODs with 4 different STOP codes since applying the updates. It doesn't even have the decency to fall over with the same error.

Disabling the Spectre mitigation has stopped the WHEA events (hopefully the STOPs as well, time will tell), by setting the following DWORD to 1:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

REG_DWORD FeatureSettingsOverride = 1

So it seems we have to choose between stability and security, although this at least leaves the Meltdown mitigation in place. Hopefully Intel can push out a less crap microcode update at some point in the near future.

[Anonymous Coward]

Re: Had to disable Spectre mitigation

Also need to set FeatureSettingsOverrideMask, both DWORDS should be 3 if my reading of documentation is correct

[Anonymous Coward]

Re: Had to disable Spectre mitigation

The mask has to be 3 as it specifies which bits in the DWORD are relevant.

If you set FeatureSettingsOverride to 3 it disables both Meltdown and Spectre mitigations. If you set it to 1 it only disables Spectre mitigation.

[Jonathan 27]

Re: Had to disable Spectre mitigation

I've updated two systems with the full set of microcode and Windows patches, a Dell XPS 9550 and a desktop with a Gigabyte Z170-Gaming 7 and niether has experienced any blue screens. It's a pretty small sample however, and both systems have derivatives of the same CPU design i7-6700k and i7-6700HQ (sky lake 4 core). Those are my personal machines, we're leaving the business ones a while to see.

[Anonymous Coward]

Re: Had to disable Spectre mitigation

Typing

$ grep . /sys/devices/system/cpu/vulnerabilities/*

into a Linux terminal window now reveals whether you've ever used anything Unix-y before, or whether you just copy shit from stackoverflow and hope no-one notices. But we noticed. What's wrong with cat?

[Michael Wojcik]

Re: Had to disable Spectre mitigation

What's wrong with cat?

That grep command line isn't quite the same as cat - it will only display non-empty lines, because "." requires at least one character on the line (and grep doesn't consider the terminating LF a character).

So if the input contains a lot of blank lines, grep is probably more useful than cat.

But yeah. Oldtimers may remember the Useless Use of Cat (UUOC) award that was frequently handed out on comp.os.unix; this is probably a case of No, This Time You Should Have Used Cat.

[streaky]

Google and Intel;

Mishandled all this right from the start. Google will get away with it because they don't make CPUs.. Intel, not so much.

Some things should stay buried, at least until there are proper hardware fixes and Intel (or anybody else) shouldn't be selling CPUs still at this point that are still vulnerable, not least because there's nothing to sue for a replacement for, which I'm sure Intel knows. Long term it's going to hurt them though.

[Michael Habel]

Re: Google and Intel;

Perhaps we'll finally see ARM on the Desktop running some Linux variant? Otherwise I think Intel having a damned near monopoly in the CPU market will be enough to see them through.

Yeah there is AMD... Perhaps if they can beat Intel to the punch they could get good again. But I fear the days of 3DNow are over for them.

[big_D]

Re: Google and Intel;

ARM is also affected, to a lesser degree, like AMD. Nobody comes out of this smelling like roses.

[Anonymous Coward]

Intel "shouldn't be selling CPUs?"

Even if it can be fixed via software? Or would a fix that reduced performance by even 0.01% be unacceptable to you?

Do you understand how long the design cycle is for making the type of architectural changes that would be required to fix this in hardware? Intel would have stopped selling CPUs in June (without explanation) and not start selling them again until the end of this year at the very earliest.

What's the world supposed to do for CPUs in the meantime? Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied. So that's not exactly a good solution. But the bigger problem is that they can't possibly make enough to supply the market, and PC sellers can't just slot in an AMD CPU to their existing models. It would take 6-9 months for them to redesign them to accommodate AMD CPUs on an AMD motherboard with AMD drivers - though realistically we all know Intel would be telling them "we will have new CPUs for you before you can get those AMD machines out, so don't even bother trying" and by the time the PC OEMs figured out Intel was lying they'd have the new CPUs almost ready.

Your suggestion would quite likely cause enough of a hit to the world economy to be noticeable in the GDPs of the US, EU, and China. Meltdown / Spectre are bad, but far from end of the world bad.

[big_D]

Re: Intel "shouldn't be selling CPUs?"

And it isn't just Intel.

AMD, ARM, Apple, IBM, Oracle are all affected by Spectre, so there wouldn't be any chips for pretty much all mainstream hardware.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

> Even if it can be fixed via software?

Spectre can't be mitigated in software, Genius.

It could conceivably be mitigated in the compiler, but that would lead to an unacceptable performance penalty. I.e. flush the L1 I-cache on each and every single branch target. Or re-write each and every single branch target to emit an instruction that can't be executed speculatively.

And I'm not even 100% certain that either of these would mitigate for the case of an unconditional branch such as call foo@plt.

Either way, the performance penalty is very high, and it requires a full recompilation of all the software, because the cure is in the compiler's codegen. Not something that can be cured with a software patch.

[big_D]

Re: Intel "shouldn't be selling CPUs?"

I though Retproline (Return Trampoline) was the compiler mitigation and is built in as a flag on the current gcc version and causes a negligible performance hit.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

> causes a negligible performance hit.

s/negligible//g

Try it on your own and see how "negligible" it is. As in not negligible at all.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

"I though Retproline (Return Trampoline) was the compiler mitigation and is built in as a flag on the current gcc version and causes a negligible performance hit."

Retpoline only helps with Spectre Variant 2, not Variant 1.

[FIA]

Re: Intel "shouldn't be selling CPUs?"

Spectre can't be mitigated in software, Genius.

[Snip software mitigation]

And I'm not even 100% certain that either of these would mitigate for the case of an unconditional branch such as call foo@plt.

And you'd be speculating what on an unconditional branch exactly?

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

> And you'd be speculating what on an unconditional branch exactly?

Do you even understand speculative execution, or are you just doing clueless blabbing on the Internet because you have a keyboard?

I'm betting on clueless blabbing. Go back to writing Excel macros.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

Do you even understand speculative execution,

Better that you do, or perhaps you just have a problem with English? If a branch is unconditional (as you wrote) there is no speculation involved, since there's only one option the branch can take.

I'm betting on clueless blabbing. Go back to writing Excel macros.

Maybe you should get some sleep, or go back to a forum where your arrogant know-all attitide is likely to be better tolerated.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

> If a branch is unconditional (as you wrote) there is no speculation involved

Wrong. There is. See ret.

> [ ... ] go back to a forum where your arrogant know-all attitide is likely to be better tolerated.

Spare me the pontificating.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

Wrong. There is. See ret.

Not an unconditional branch, since the destination isn't 100% known.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

> Not an unconditional branch, since the destination isn't 100% known.

Wrong again. The return register is always known. And if you're dealing with a large struct, where one or more struct elements would be returned outside the return register, these registers are also always known.

[Phil O'Sophical]

Re: Intel "shouldn't be selling CPUs?"

The return register is always known

So how can a branch using it be speculative? Surely you only speculate when you don't know something for certain?

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

> Surely you only speculate when you don't know something for certain?

That's not how it works.

Speculative execution means that the CPU will decide to take a given branch because the branch predictor has guessed that this branch will be taken. This speculative branch is taken while other instructions are in-flight.

It then turns out that the branch predictor guessed wrong, and that guessed branch was not taken, maybe due to the completion of the then in-flight instructions, which made the branch predictor's guess wrong.

In this case, the speculative and out-of-order executed instructions must be rolled back - kind of like a relational database rollback transaction, but not quite. Unlike a relational database, where everything gets rolled back, certain side-effects of the speculative execution are not rolled back. One of these things is the L1 I-cache. The I-cache is not flushed because (a) replenishing it would be very expensive and (b) some of the instructions in the cache can still be re-used.

So, there you have it.

For example: a function can have several return statements, all of them predicated by conditionals:

if (some_condition_is_true()) {

do_mumble_foo();

return show_me_an_elephant();

} else if (some_other_condition_is_true()) {

do_mumble_bar();

return show_me_a_giraffe();

}

do_mumble_baz();

return show_me_a_dolphin();

You have 2 different conditional branches here. There are 8 branches in total, but I'm simplifying - I'm not counting the call and ret instructions that happen here.

The branches terminate with same exact return address and register - which is the function's return address and register.

Let's say that the branch predictor guesses that some_other_condition_is_true() returns ~0. But at run-time, some_condition_is_true() returns ~0 instead. Or neither of the condition() functions return ~0, and the code path falls through to do_mumble_baz(). In either case, the branch predictor guessed wrong. The speculative execution that happened based on the branch predictor's guess has taken the wrong branch, and now that out-of-order execution must be discarded (rolled back).

[Phil O'Sophical]

Re: Intel "shouldn't be selling CPUs?"

Speculative execution means that the CPU will decide to take a given branch because the branch predictor has guessed that this branch will be taken. This speculative branch is taken while other instructions are in-flight.

Yes, that I understand.

My confusion was that I was assuming that "conditional branch" meant something like a single "branch if xxx" instruction, whereas "unconditional branch" would be "branch always". I wasn't allowing for them to be separated, where a preceding test would later be followed by a branch always, the combination being the "conditional branch" which could be speculatively executed. Thanks.

[Michael Wojcik]

Re: Intel "shouldn't be selling CPUs?"

And you'd be speculating what on an unconditional branch exactly?

Conditional branches are not the only point of speculation. Pipelined CPUs that provide precise interrupts will are in effect speculatively executing most of the time, since they may roll back interrupted instructions under most conditions.

You could probably get an indirect load to speculatively execute in a manner that leaks information through cache timing, if you can find a gadget with a suitable structure.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

You could probably get an indirect load to speculatively execute in a manner that leaks information through cache timing, if you can find a gadget with a suitable structure.

a.k.a. Meltdown.

[JeffyPoooh]

Re: Intel "shouldn't be selling CPUs?"

ST suggested, "It could conceivably be mitigated in the compiler..."

What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler ?

I'm not sure that the basic concept of securing the world's CPUs in "the" (?) complier makes much sense.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

> What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler?

That's exactly what makes Spectre so toxic. It doesn't even require any kind of special (i.e. root) privileges to work.

Imagine some innocent-looking program that runs as a "regular" user, and exploits Spectre. It won't leave any trace at all.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

ST suggested, "It could conceivably be mitigated in the compiler..."

What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler ?

It's not the bad guy's code you worry about. He wrote it, so he has no need for tricks to see what it is doing. It's the code under attack that needs protection.

The problem with one of the Spectre variants is that the bad guy can write code which trains the branch predictor in certain circumstances (for certain addresses), then when the code under attack reaches a relevant branch he can use that trained prediction to leak information he shouldn't be able to get at.

The compiler changes are to modify the attacked code, not the attacker's code, so that it can't be influenced by the attacker. Blocking all prediction would work, but have an extreme performance hit, so the combination of new microcode & compiler changes is supposed to allow critical code to be protected while minimizing the hit. Far from simple, and a PITA if every kernel & VM needs to be recompiled with the new compiler.

The fix doesn't need to be perfect, though. Just as crypto doesn't need to be unbreakable, just too hard to break in a reasonable time, the Spectre mitigation just needs to make the attack too slow to be useful. If the attack on mitigated code creates a side channel that can only leak, say, 1 bit every 5 minutes, it will likely take too long to get anything useful before the next restart, reboot or other significant change.

[jmch]

Re: Intel "shouldn't be selling CPUs?"

"Even if it can be fixed via software? Or would a fix that reduced performance by even 0.01% be unacceptable to you?"

It CAN'T be fixed by software. It can be (partly or mostly) mitigated. If it could be fixed with a 0.01% performance loss no-one would be kicking up the stink that they are, but reality is that it can be mitigated with a perforance hit of anywhere between 5-20% judging by reports I've seen.

Can you imagine if you paid north of 30 grand for a car with 200 bhp, and the manufacturer says hey, the brakes might fail at any given moment, very unlikely to happen guv, but here's a fix and by the way, your car now has 160bhp not 200.

[jmch]

Re: Intel "shouldn't be selling CPUs?"

"What's the world supposed to do for CPUs in the meantime?"

At least customers can have some informed consent on the chips they have been buying in last 6 months that Intel KNEW were borked (and possibly they knew of the flaw even before 6 months ago). I'd expect at least a discount / partial refund on any chips bought in the last 6 months. And given that Intel had 6 months to work on a software mitigation patch, isn't the least to be expected that it was properly tested? Maybe the Register jumped the gun by a couple of days, but the disclosure was due anyway, Intel should have thrown as much resources as it took to fix this on time.

"Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied"

I'm not an expert on chip performance is this confirmed anywhere? Anyone?

[Brewster's Angle Grinder]

Re: Intel "shouldn't be selling CPUs?"

>>Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied

>I'm not an expert on chip performance is this confirmed anywhere? Anyone?

Yup, it's been confirmed. By Intel's marketing department.

[Bronek Kozicki]

Re: Intel "shouldn't be selling CPUs?"

AMD is known to be not affected by Meltdown bug, which was also the most expensive (in terms of performance penalty) one to fix. This means that, suddenly, all the performance benchmarks comparing Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary) against AMD ones (which would not allow such violation in its own, slightly less buggy, implementation of speculative execution) are no longer valid.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary)

No. You got this 100% wrong. This is not what Spectre does. You are confusing Spectre with Meltdown.

And it's not just Intel that has crappy buggy speculative execution.

Every single chip that has speculative execution - which means all general-purpose chips designed and fabricated in the past 20+ years, with the exception of Itanium - is affected by Spectre.

And no, it's not a matter of buggy or crappy. It was a design oversight, or short-sightedness if you will, at the time, combined with the notion that nobody is smart enough to figure this out, and with pressure from benchmarketing types.

The Spectre vulnerability was being whispered around in interested circles much earlier than June 2017.

[Bronek Kozicki]

Re: Intel "shouldn't be selling CPUs?"

@ST you are right and I am right - I was referring to Meltdown (not to Specre) so we agree on this. The speculative execution on its own can also cause Spectre "class" of bugs which are cheaper (performance wise) to work around, as compared to Meltdown one. The numbers I keep seeing on lwn.net for Specre are consistently under 5% (usually around 1%), but numbers for Meltdown easily exceed 10% if your system is doing little more IO or other kernel-related activities. This is why I believe that AMD (not being affected by Meltdown) have now huge performance win against Intel, which is not reflected by old benchmarks, at all. On related note - I wonder if GPU intensive application (i.e. games) need context switch to communicate with the GPU. If so, then gaming benchmarks are going to be affected a lot, too.

You are also right on explaining that speculative execution issue is not just "implementation", it is more of a design issue. Just let me have that simplification, ok?

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

Just let me have that simplification, ok?

I think we're both saying the same exact thing, just using different words.

[JohnFen]

Re: Intel "shouldn't be selling CPUs?"

"And no, it's not a matter of buggy or crappy. It was a design oversight"

It was indeed a design oversight, and a subtle enough one that it's hard to blame the engineers for it. However, it's still a bug -- and therefore the implementation is buggy.

[martinusher]

Re: Intel "shouldn't be selling CPUs?"

>And no, it's not a matter of buggy or crappy. It was a design oversight, or short-sightedness if you will, at the time, combined with the notion that nobody is smart enough to figure this out, and with pressure from benchmarketing types.

Its also a matter of playing the odds. Despite what the typical (noisy) consumer might think there really is no such thing as 100% anything. Designers play the odds because you're always trading off conflicting parameters, you just don't talk about it much because its difficult to explain to people that think entirely in terms of 100% or 0%. So, yes, there's a problem but how much of a problem and how the problem or a fix might affect particular users is a judgment call, especially as the problem manifests itself as an ability to slowly read information about a memory area that shouldn't contain any particularly meaningful information in the first place.

[FIA]

Re: Intel "shouldn't be selling CPUs?"

[...] benchmarks comparing Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary) against AMD ones (which would not allow such violation in its own, slightly less buggy, implementation of speculative execution)

Lets be fair here, neither chip has buggy speculative execution. This isn't a bug, the chips work as expected; it's a side channel attack, the processor leaks information that after A LOT of trial an error can be used to figure out what's in certain memory locations. It's just that trial and error on a CPU can be quite quick... and the internet allows it to be done remotely, often without the users knowledge.

I know it's only a small point, but a lot of the press, especially the less technical press are making it out like this is a huge bug that should've been noticed, rather than a perfect storm of unintended side effects that's taken 20 years to figure out.

It's like how posting your holiday photos whilst on holiday make your house more attractive to thieves. It's not your intention, or a 'bug' in Facebook, it's just an unintended consequence.

The reality is, the more complex systems become the more things like this will appear.

[JohnFen]

Re: Intel "shouldn't be selling CPUs?"

"This isn't a bug, the chips work as expected"

I suppose that depends on how you define "bug". By my definition, this is definitely a bug (unless being vulnerable to a side-channel attack was intended) -- a bug in design rather than execution, but a bug nonetheless.

"a lot of the press, especially the less technical press are making it out like this is a huge bug that should've been noticed"

I agree that this is a mischaracterization by the press. This was a very subtle thing, and it's hard to fault engineers for not noticing it.

[analyzer]

Re: Intel "shouldn't be selling CPUs?"

Well that's a little more complex than the simple faster then.

It kind of goes like this, Intel CPUs are 'on average' 30% faster than AMD Zen CPUs <--- the point where idiots stop reading <--- for single threaded workloads but there are workloads where AMD is faster. For multi threaded loads, AMD Zen CPUs are on average 13% faster than Intel but there are workloads where Intel are faster. So CPU choice is pretty much irrelevant except for outliers where one will seriously trounce the other.

The curious thing regarding servers that I never see mentioned is the actual data throughput of the system containing the CPU. As the Intel Xeon sports 44 PCIe lanes vs the 128 lanes that the AMD Epyc provides and, typically, 6 PCIe lanes are dedicated to board specific functions, that leaves Intel with only 38 to play with vs AMDs 122. This would imply that the actual throughput of an Epyc based system could be far higher than a Xeon one.

[big_D]

Re: Intel "shouldn't be selling CPUs?"

As analyzer says, it depends on what you are doing and whether you are an outlier usecase. In my case, I wasn't interested in single threaded performance, but performance for multiple virtual machines for testing on a desktop... Ryzen 7 was a no-brainer, 8 cores and 16 threads for around the price of a quad core Intel processor.

This is the first rig I've had that doesn't slow down when running multiple VMs.

[Anonymous Coward]

Re: Intel "shouldn't be selling CPUs?"

> I wasn't interested in single threaded performance, but performance for multiple virtual machines for testing on a desktop

Spectre has nothing to do with single-threaded vs. multi-threaded or running multiple VM's or anything like that.

The Spectre vulnerability is very simple: in the context of a branch mispredict speculative execution, the instructions aren't retired.

Mispredicted branches happen all the time, regardless of the number of threads, or whether you're running a VM or a relational database. What the software does is 100% irrelevant.

If you disable speculative execution competely, the performance hit is staggering: it's in the 30% ballpark.

Branches - conditional or unconditional - exist in every single type of software.

Without branches you can't have if/else statements, for/while loops, return from a function or a function calling another function.

OK, that's an over-simpification. You can have conditionals without branches, but that's a very complicated and inefficient way of doing conditional branches. You still end up in the same sore spot: huge performance hit.

[big_D]

@ST Re: Intel "shouldn't be selling CPUs?"

I think you are missing the context here.

The discussion between analyzer and myself was whether Ryzen made AMD competitive again against Intel (before Meltdown and Spectre). That, before M/S Ryzen one on some edge cases, compared to Intel and vice versa.

What you say is correct, but it has no bearing on the sub-conversation you refer to.

[Anonymous Coward]

@ST Re: Intel "shouldn't be selling CPUs?"

Spectre has nothing to do with single-threaded vs. multi-threaded or running multiple VM's or anything like that.

(S)he didn't suggest that it did, the comment was in response to allegations that AMD was always slower than intel, and the poster pointed out that for the use case in question, running multiple VMs, AMD gave better performance.

Slow down & read the comment fully before jumping in with a response.

Mispredicted branches happen all the time,

They do indeed, the big question for Spectre is whether you can train the branch predictor such that you can be fairly sure which way it will jump. If you can, you have a Spectre exploit. The compiler & code mitigations involve making it too difficult to usefully train the predictor, not in suppressing the predictions. That's why the performance hit may be tolerable.

[Anonymous Coward]

Re: @ST Intel "shouldn't be selling CPUs?"

> The compiler & code mitigations involve making it too difficult to usefully train the predictor, not in suppressing the predictions.

One of the proposed compiler-based mitigations for Spectre involves inserting an otherwise useless loop containing pause instructions (on Intel) for each and every single branch target. This will suppress speculative execution, because pause cannot be executed speculatively.

Not all ISA's have pause, so what applies to Intel won't apply to other ISA's.

So, my question is: what is the difference - in practical terms - between making it too difficult to usefully train the predictor and suppressing the predictions?

[Tom Paine]

Re: Intel "shouldn't be selling CPUs?"

To be fair, this is pretty much the worst possible case for computer security; a fundamental defect in an architectural design pattern adopted by multiple part manufacturers for decades. I can only dimly imagine how bad a day that must have been at the Intel security team when the first mail arrived.

[elip]

Re: Intel "shouldn't be selling CPUs?"

I'm more than a little bit distressed by the fact that Intel, ARM, AMD, Google etc. knew about this flaw for half of a year, but kept Oracle and IBM (and other smaller RISC vendors) completely in the dark. I understand, and completely disagree, with software-only security embargoes, as it effectively penalizes the smaller developers and open source projects, which ultimately hurts users' security. However, in this case, the owners of 80-90% of the world's running machines, in my opinion, *colluded* to keep these older RISC vendors out of the loop, while they developed mitigations and designs to improve their future products. They did this knowingly, and willfully. I have a feeling and hope, some very large, very reckless companies are going to be facing legal battles.

[Teiwaz]

Re: Intel "shouldn't be selling CPUs?"

What's the world supposed to do for CPUs in the meantime?

Cue : Penny Farthing Logo.

Maybe it's a good opportunity to slow down and take stock of where the world is headed rather than continue the knees bent, running about advancing behaviour blindly, up up the ziggurat lickity split...

No takers? thought not.

[Random Handle]

Re: Intel "shouldn't be selling CPUs?"

>Maybe it's a good opportunity to slow down and take stock

First thing the CEO did.

[big_D]

@Randome Handle Re: Intel "shouldn't be selling CPUs?"

>Maybe it's a good opportunity to slow down and take sell stock

First thing the CEO did.

There, FTFY.

[GreenReaper]

Re: Intel "shouldn't be selling CPUs?"

It's really not a bad time, as the market is pushing its all-time highs. Intel's probably not the only stock that'll be melting down in 2018.

[Chronos]

Re: Intel "shouldn't be selling CPUs?"

Maybe it's a good opportunity to slow down and take stock of where the world is headed rather than continue the knees bent, running about advancing behaviour blindly, up up the ziggurat lickity split...

I could only give this one upvote when it deserves three: One for the philosophy, and one each for the Python and Dwarf references.

The fact that this came about in the blind pursuit of speed über alles makes the performance hit all the more ironic. Had this been any other sector but the whale-song-fuelled tech industry where "we do because we can," where all ideas are delivered in a Californian accent complete with uptalk and riddled with buzzwords we'd be seeing a massive land-shark mobilisation by now. Hell, even governments would be salivating at the punitive fines they could levy for the amount of customer-fuckery this has generated.

We do need to take a step back, not only to examine the efficacy of harder, better, faster, stronger but also what the current plethora of technical advances such as automation and convenience is doing to humanity's ability to survive. We're already only a few megawatts away from looting and anarchy. Do we push on and make that looting, anarchy and extinction?

[robzap123]

Re: Intel "shouldn't be selling CPUs?"

I'm not one for dwelling in the past, but the relentless upgrade cycle that is a product of marketing departments urged on by sales departments, who are in turn urged on by heads of corporations who are hell-bent on pleasing their stockholders so that they can take bigger bonuses, is making no sense at all! There are some really pressing environmental issues threatening the medium-long term existence of life on this planet that we need to address urgently! Whether we use computers that can process at 100 teraflops or 2 teraflops, is that going to make any difference to how we solve those problems? Just the sheer quantity of resources that are wasted in the upgrading of systems that enable process of computing complex mathematical models that confirm the bleedin' obvious makes me feel sad. Of all the e-waste that is generated, how much of it is actually recycled without causing more pollution and bad health outcomes? All the extra computing power enabled by "faster everything" is squandered by inefficient and porous code that make the hackers rub their hands together. How productive can you be if your software doesn't work properly, isn't supported properly and the target of hackers? Get real everyone!

[Wade Burchette]

Re: Intel "shouldn't be selling CPUs?"

Um ... Have you seen the benchmarks for Ryzen and Eypc? The only area where Intel has a clear advantage anymore is gaming, on everything else Ryzen goes toe-to-toe with Core i-whatever. And in servers, Eypc is actually was better dollar-for-dollar than anything Intel has to offer before these patches. You can buy 32 core Eypc processors for much much less than a 24 core Xeon. AMD is competitive again. The issue is perception and Intel's marketing. Intel helps fund commercials for companies which promote their product. This is a standard practice, because I have a friend in the HVAC business who has ads paid for by Carrier corporation for his business because he sells a lot of their units. AMD doesn't have the cash to overcome perception and marketing just yet.

Another thing, it takes about 2 years from design to production for each new CPU. Assuming Intel learned about this in July of 2017 and started right away fixing it, that would put them at July 2019 before they have a fixed CPU. And that is pretending they also knew about Spectre at the time too. Pretending AMD learned about Spectre recently, that would put them in January 2020 before they have a patched CPU too.

Intel does lie. What they have been telling people is that AMD is affected too, they have just not told them that AMD is not affected as much as Intel is.

[Martin an gof]

Re: Intel "shouldn't be selling CPUs?"

AMD is competitive again

It seems to me that AMD has been highly competitive in the low- and mid-range market for quite some time. While the per-thread performance of the A-series chips doesn't quite match that of low-end Intel chips, the package as a whole (i.e. when you include graphics, motherboards) for self-builders has worked out cheaper and better, which is why I have been building AMD-based machines for some years now. If the impact of Meltdown and Spectre mitigations really is lower on AMD than Intel, even the per-thread gap will be reduced.

There is also less software which is purely single-threaded, meaning that it makes even more sense to go for AMD where you can get more cores for the same money.

I've not been in the extreme high-performance end of the market, but it looks as if Ryzen is a very serious contender if ever I decide to build a gaming rig, or if I want to speed up Kdenlive (MELT) video rendering - this is CPU-bound and doesn't use the graphics card.

M.

[CrazyOldCatMan]

Re: Intel "shouldn't be selling CPUs?"

Even if it can be fixed via software?

It can't. At best it can be mitigated, not fixed. Now I'm not suggesting that Intel stops producing processors, more that they be a lot more open about the effects of the bugs and their plans to fix it.

The same holds (to a lesser extent) for the other processor manufacturers and OS vendors.

And best of all, stop producing patches that make machines unstable or non-bootable.

[Tom Paine]

Re: Intel "shouldn't be selling CPUs?"

You appear to be labouring under the misapprehension that a hardware fix (modified architecture) won't have a performance hit...

[Doctor Syntax]

Re: Google and Intel;

"Intel (or anybody else) shouldn't be selling CPUs still at this point that are still vulnerable"

So what are they going to sell instead? What system level products are ready to take it? And who's going to roll out software recompiled for this mythical product?

The reality is that users still need to get kit installed and can't wait several years for redesigned products to become available.

[Tom Paine]

Re: Google and Intel;

But if Intel stopped selling known-dug devicesm they'd have had to - wait, that is. They can't, but what happens if they have to? What happens if some unlikely but conceivable incident destroys the 5 biggest fabs for x86 class devices in the world simultaneously? What happens if Intel goes insolvent and ceases trading? and so on and so forth

[streaky]

Re: Google and Intel;

So what are they going to sell instead?

Seats in the bankruptcy court.

Like Gemalto before they probably shouldn't exist at this point.

If Ford had a car where the steering wheel would randomly snap off and kill the driver nobody would buy fords until ford had a fix in place. Actually what would happen is ford would recall all the affected cars.

Oh wait too much logic. Intel still flogging CPUs not fit for purpose, so are, yes, many other companies - sux to be huge and the focus.

Said it before and I'll say it again, it's not clear we shouldn't have all gone back to living in mud huts over this. There are going to be new classes of bugs that derive from this flaw for years to come, somebody needs to do something about it in hardware, which means yes, you guessed it.

[Anonymous Coward]

Re: Google and Intel;

"Some things should stay buried, at least until there are proper hardware fixes and Intel (or anybody else) shouldn't be selling CPUs still at this point that are still vulnerable..."

That's an oxymoron because you can't do both; as soon as Intel (or anybody else) stopped selling vulnerable CPUs (which in this case would mean all CPUs) it would tell you that not only has something been buried but also where it has been buried.

[rdhood]

Re: Google and Intel;

"Intel shouldn't be selling CPUs still at this point that are still vulnerable,"

Bingo. Or, at the very least, they need to release new performance numbers and admit that they have lost the speed crown.

[MacroRodent]

Software has to pay attention

It looks like CPU hardware will not be getting faster for a while, with the microcode and OS patches slowing down even existing CPU:s, and Intel&AMD having to go back to the drawing board, delaying new releases. So software writers (whether proprietary or open source) cannot now rely on CPU speed growth to mask the bloat new versions introduce. This could actually have a positive effect on software quality.

[big_D]

Re: Software has to pay attention

It is also a boon for old-school programmers, who were brought up to think in clock cycles and who actually know how a processor works, and therefore how best to optimize code.

I liked Steve Gibson's description of his Inspectre tool. It is a 122KB (yes, KB) tool to detect Meltdown and Spectre vulnerabilities on Windows PCs (should also work with WINE for Mac and Linux). He moaned that, of the 122KB ,96KB was needed for the damned hi-res, "hi-color" icon that Windows requires.

[Anonymous Coward]

Re: Software has to pay attention

"It is also a boon for old-school programmers, who were brought up to think in clock cycles and who actually know how a processor works, and therefore how best to optimize code."

Trying to beat the slowdown by converting some of my Excel VBA to a VB.Net DLL

The VBA conversion application COM module available on the web failed to be recognised by Excel - so after several attempts I did the conversion myself in Visual Studio 2012.

Conversion of a function that was a known cpu hogger was surprisingly easy. First tests showed it ran 20 times faster than its VBA original and produced identical results. Over the full run that alone would save several hours.

That was nearly a week ago. Since then I have been chasing my tail trying to pass a parameter to the DLL function. It consists of a user type which also contains other user data types. I keep trying to imagine how the underlying type libraries, marshalling, and data structures work at the code level.

It is times like this when you find that the available Google information is basically recipes about what to type - with examples that use the simplest cases. Deep understanding seems to be considered unnecessary. I can see a bodge circumvention to get the data through piecemeal - but it will not satisfy my soul.

I am reminded yet again of E.M.Forster's "The Machine Stops". Technological towers of Babel with foundations of shifting sand - on which we have come to depend.

[Martin an gof]

Re: Software has to pay attention

Since then I have been chasing my tail trying to pass a parameter to the DLL function

I - even though merely a code "dabbler" in comparison - feel your pain. My current nightmare is trying to read "stream" output (i.e. stdout) from a command in a non-blocking manner - I can set the thing off from Python, but then I need to "do other things" while the command executes, and check every now and then for output. All the recommended methods either insist on waiting until the command has terminated (this is a looping video player so it won't terminate), or will block if the stream is empty (which it usually is if there are no errors).

Current best bet seems to be using a timeout, but as you say, this doesn't "satisfy my soul". WHY does reading from a stream have to block? Why can't it return empty if there's nothing to read? Why doesn't there seem to be a way to check if there's data in the stream?

M.

(Just watch some know-it-all point me at a very easy solution... I said I was just a dabbler!)

[KSM-AZ]

Re: Software has to pay attention

Not easy per se, not generally difficult.

You have to either set the iostream to NONBLOCK or use a select call. The issue in a pipe/ipc is the stream you are reading from and how buggy your select() function is.

Select can be a real bitch, you have to load your file descriptors you want to monitor in arrays for read write, give it a count with a timeout 0. I wrote a simplified C function long ago along the lines of has_data(int fd) ... nested in a readline function. If you can get NONBLOCK on your stream you can just do a read(int fd, char *buf...) and it will return 0 if you got nuthin. Much fun with ioctl's on serial lines and other character devices.

YMMV

[AMBxx]

Re: Software has to pay attention

Thanks for the heads up on Gibson's tool. I had all the Windows patches installed, but still vulnerable to sepctre. I now have a fun day hunting for BIOS updates, but at least I know there's a problem.

[bazza]

But we've also heard an industry-wide silence about CPU-makers’ roadmaps for a Meltdown-and-Spectre-free future. Rumours are rife that a generation of products will have to be redesigned, at unknowable expense and after un-guessable amounts of time.

It varies. Right now I'm not sure that Intel has anything in its product portfolios that you'd actually want to buy. AMD, Oracle SPARC and IBM Power are less affected but they still have to sort out Spectre.

So far as I can see the only sure way out of this is to not use speculative execution. Welcome back to the Dark Ages of CPU architectures. Things will get very slow...

Whilst there's a single cache, memory system and speculative execution there is no true fix for this. One could lock the cache whilst a branch is executing, but then you would have to wonder about thread preemption. It's a real mess.

[Lysenko]

So far as I can see the only sure way out of this is to not use speculative execution. Welcome back to the Dark Ages of CPU architectures. Things will get very slow...

...or return to treating kernel protection as the accidental bug mitigation strategy it was intended to be rather than a security feature. If conventional malware gets onto one of my systems then it's already "game over" as far as I'm concerned (or at least I'm prepared to accept that premise), so the main remaining challenge is locking down interpreters that download crap over the internet without conventional installation procedures (principally, JavaScript engines).

There are plenty of processors (mostly microcontrollers) that have no concept of kernel protection or user access control. If the code is on the chip it has root/ring 0 access because that's the only sort that exists. That doesn't make them unusable, it just forces you to pay more attention to perimeter security.

[Doctor Syntax]

"the main remaining challenge is locking down interpreters that download crap over the internet without conventional installation procedures (principally, JavaScript engines)."

Could this induce web designers to turn their backs on JavaScript?

[Brewster's Angle Grinder]

"Could this induce web designers to turn their backs on JavaScript?"

No. Because the OP's "problem" is "download[ing] crap over the internet without conventional installation procedures"; not the language used once the stuff is downloaded. You could be web scripiting in C++ (via WASM) and he'd still have the same problem.

[Warm Braw]

conventional malware

Unfortunately, given that you can potentially exploit these bugs from JavaScript on a web page, you're at risk from a far greater range of potential malware than one might at first imagine. And if you provide a public cloud service, you have to be robust against even unconventional malware.

That said, the meltdown issue wouldn't be a problem (necessarily) if the kernel memory were encrypted - though you'd have to be reasonably convinced that the encryption key wasn't exposed and that, having downloaded the contents of encrypted memory, an attacker then having the time and resources couldn't brute-force the key by some means (and it is quite likely that there will be known data patterns at various kernel addresses).

Spectre is more of a problem, but it could potentially be dealt with by having "sandboxed" code (such as JavaScript...) run in an address space separate from that of the host process and the latter also having its memory encrypted - the same caveats applying.

It might be OK to ignore the problem on your own particular desktop computer, but if the cloud providers want to stay in business these issues have to be fixed.

[big_D]

The problem is, they have been handed a "bug" that basically says, "everything you've learnt about chip design in the last 20 years is wrong, go back to the drawingboard."

That is not something that you can correct for in a few weeks or months.

[MacroRodent]

Raise the Itanic!

So far as I can see the only sure way out of this is to not use speculative execution. Welcome back to the Dark Ages of CPU architectures. Things will get very slow...

Or use explicit parallelism with wide instructions, like Intel Itanium...

[Anonymous Coward]

AMD, Oracle SPARC and IBM Power

A nitpick, it isn't Oracle SPARC. SPARC is an open source processor architecture managed by SPARC International, both Oracle and Fujitsu design and make SPARC processors

the only sure way out of this is to not use speculative execution

That's extreme. You just need to make sure that the speculation doesn't leave visible side effects, such as cache entries, that can be read through a side channel. It's not the speculation that's the problem, it's the implementation of it.

[GreenReaper]

It probably is Oracle SPARC, though, because not every SPARC processor has this kind of architecture based on speculation.

It may also be other SPARC, yet still not SPARC in general. It's only X86 in general because speculative execution has been a feature of the platform for such a long time that almost everyone adopted it.

[KSM-AZ]

Correct me if I'm wrong. . .

These bugs allow someone already on the machine to read memory they shouldn't by crafting a specially designed program.

Then you have to make some sense out of what you managed to see.

So basically you get to sift thru gb of constantly changing data and try and spot something useful.

Not saying it can't be done, but from a threat perspective, or attack vector this seems way more difficult than dropping USB sticks outside the building. . . Enlighten me with something you can actually accomplish with some kind of timeframe and numbers. Don't get me wrong it should be addressed but multiplying floats wrong seems a lot more dangerous than this.

[Anonymous Coward]

Because it is now trivial to run a user process (like a web page in a browser) and have it read the kernel where all your account passwords and system authentication is, regardless of operating system.

[Doctor Syntax]

"Because it is now trivial"

A bald statement that it's trivial doesn't really answer the OPs request for enlightenment. If it's trivial how about appending a few lines of code that show just how trivial it is?

[donk1]

Meltdown exploit - https://github.com/IAIK/meltdown

Videos of Meltdown in action - https://spectreattack.com/

[hammarbtyp]

keep calm and carry on

@KSM-AZ is asking the correct questions rather than all this, there's an exploit, we're all going to die bullsh*t

The potential exploit is a proof of concept on a processor, but processors run on systems and there is a layered approach to defenses which a potential hacker needs to overcome. This is however a long way from producing a universal exploit on a real system that can actually do some damage

When dealing with such situations, it is not the exploit that is looked at but the risk. Risk is measured against a whole range of parameters such as threat, vulnerability, technical factors, and possible damage. If you are running a home PC your risks have probably not increased measurably, your 1st line of defence is good cyber awareness, latest patches and hopefully anti-virus makers will get good at identifying malware trying to run this exploit. There is no value is kick dropping your PC out the window and waiting for more secure chips. (Probably the biggest risk is via Javascript, but those are relatively easily managed by restricting access to high accuracy timers )

If you are something like a financial organisation, your risks are higher, but so are the safeguards and the difficulties applying the exploit, so same applies.

This is not to underestimate the possible seriousness of the exploit or that fact their appears to be no easy software fix but the basic fundamentals of cyber security have not changed. The risk needle has moved slightly, but not to the point where the world is coming to an end. so keep calm and carry on

[Anonymous Coward]

Still no patches for...

VMware ESX or many versions of Windows

[Pascal Monett]

Ummm

As far as Microsoft is concerned, there is only one version of Windows.

All users of other versions have already been told to take a hike.

[donk1]

Re: Ummm

http://smooth1.co.uk/security/CPU_issues.html#1.1.4.1

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002 includes Windows 7/8.1

Also see https://portal.msrc.microsoft.com/en-us/security-guidance

[Deckard_C]

Re: Still no patches for...

No meltdown fix for 32bit (x86) versions of Windows

See FAQ Q4 https://support.microsoft.com/help/4073119

Which seems to be mostly overlooked

[Steve Davies 3]

And the bright side is...

The company also revealed that data centre workloads will be slower after it’s done patching.

Amazon , parts of Microsoft, etc will be rejoicing as the services where they charge by the minute suddenly got a bit more profitable.

[Anonymous Coward]

Re: And the bright side is...

... once they've spent lots to on kit to keep the same heardroom and paid the power bill for the extra kit.

[The Kernal]

Gotta love fixes that break things

Did all the updates, intel updates, updated too the new Oracle VirtualBox, and what do I get for staying up to date. A lubuntu VM that no longer streams video without the audio becoming corrupted after more than 3 minutes. Thanks for the new features... your the best intel.

[Anonymous Coward]

One step at a time

Intel has trashed Moore's Law. Oh, the irony.

[dom_f]

Re: One step at a time

Moore's law is about the number of transistors, not execution speed, so no they haven't.....

[JeffyPoooh]

Re: One step at a time

dom_f noted correctly that "Moore's law is about the number of transistors, not execution speed..."

Ah, but what are the extra transistors *for*?

Often storage yes, but also multiple parallel cores on one chip is another common application for additional transistors. Not to mention fancy features such as Speculative / Out Of Order Execution.

The good news is that -10% is just a few months worth anyway.

[teknopaul]

3 weeks of work

I started an unplanned upgrade cycle the moment I read the reg article.

What with all the broken patching going on and general probs you always see when upgrading to the bleeding edge its been a fun 3 weeks. Saw Linux crash for the first time in as long as I can remember and unplanned, highly annoying, Windows reboots in the middle.

Thankfully nothing bricked.

Yet.

[Anonymous Coward]

Re: 3 weeks of work

I started an unplanned upgrade cycle the moment I read the reg article.

That was your first mistake. This is nowhere near as critical as, for instance, heartbleed.

And the delay between its discovery and mitigation coming out gives a clue about the difficulty of same - and thus the likelihood of installation difficulties occurring,

Just stick to your normal cycle :-)

[Steve K]

A tactical mitigation/solution...?

Here's a (semi-serious) mitigation/solution.

Performance hit is (say 10%), so what manufacturers do (with the CPU vendor's blessing) is permit a 10% overclock - say matched with XMP profiles matched to the motherboard/chipset/CPU combination for supported SKUs) carefully controlled through the BIOS/MoBo firmware so that the overclock parameters are validated and supported under a warranty extension.

This would affect larger-scale operations as their power/cooling bills would go up accordingly AND presumably the additional power load might cause some additional issues (e.g. reduced density due to increased load on power supply. UPS capacity, stress on CPU and other components leading to higher failure rates and swap-outs, individual PSUs at capacity so unable to deliver any more power so unfeasible).

There would have to be a limit as to how much higher you could go (i.e. for the workloads suffering by 20% that might be too high to push it)

Replacing CPUs due to overclock stress might be a tactic for Intel/AMD/ARM etc. at least in the medium term, although the effect on other components' warranty (i.e. from server OEMs) would be hard to gauge.

Is any the above feasible? I know it's not necessarily easy (at scale) to do it so won't work for everyone.

[Gordon 10]

Re: A tactical mitigation/solution...?

Interesting potential solution, for a which I can see a few potential problems.

1. Modern CPU's already overclock like crazy (aka TurboBoost)

2. Statistical distributions will come into play - some proportion of chips will go unstable at a 1-2% overclock.

3. (Intel) Marketing would see it as "free gear" and kill it with fire.

[Anonymous Coward]

Re: A tactical mitigation/solution...?

If a chip could reliably run at 10% overclock, don't you think the manufacturers would sell it as a 10% faster part?

[Luiz Abdala]

Re: A tactical mitigation/solution...?

If a chip can be reliably run at 10% overclock, they will give a new marketing moniker to sell it for 20% more.

Locked multipliers chips were sold SOLELY based on that. Entire generations of Celerons were underclocked gems that could be taken into stratospheric overclocks, provided you could cool them and the memory could keep up with them.

The entire overclock community was BORN exclusively of the fact that some CPUs were being purposely throttled and sold under different price tags, and someone discovered that the 50$ chip could perform just as much the 100$ chip, and the 100$ chip was the the same 50$ part, overclocked into the edge of electronic migration.

One certain old-school AMD chip was even "hard-locked", but this could be unlocked/overclocked if you shorted 2 pins.

[Patrician]

Re: A tactical mitigation/solution...?

"One certain old-school AMD chip was even "hard-locked", but this could be unlocked/overclocked if you shorted 2 pins."

With a pencil if memory serves ....

[Anonymous Coward]

It represents a great opportunity for ms to screw over windows 7 users with performance hits to drive them to windows 10.

[Anonymous Coward]

A friend rang yesterday saying that W7 update was refusing to check for updates - it said it was broken.

Directed her to the MS web page for trouble-shooting Windows update. She selected "W7" - and the web page said the solution was "Update to W10".

Only when she ticked the box to say "no W10 update" - did the page reveal the trouble shooting steps for W7. Looks like MS are up to their tricks again with gullible users.

[Doctor Syntax]

"Looks like MS are up to their tricks again with gullible users."

Again?

[GreenReaper]

Might be part of the solution, nevertheless. If it's going into the kernel all the time to render font glyphs, that's gonna cost more you now.

[anthonyhegedus]

From a computer science standpoint, how is it that multiple processors from more than one manufacturer have the same flaw? Is the whole concept of speculative execution taught wrong at all major universities?

And how come AMD managed to remember to design their processors without this flaw?

I wonder how long this has been known about, and at what point someone realised that this flaw could be used for something malicious?

I know it almost doesn't matter now, because we have this problem and need to work with it, but I'm just curious as to how such a simple flaw kept under the radar for so long?

[thondwe]

Nothing wrong with Speculative Execution - Just that no one covered the SECURITY DESIGN for it properly.

Expecting a next generation of CPUs to get this right - live in hope!

[Orv]

Because it may be simple in concept, but it's not *obvious*. Those are different things. It's not that speculative execution is flawed, exactly, it's that its implementation in real-world systems leaves room for a timing attack that leaks information.

This isn't a direct analogy, but imagine you were trying to figure out the precise route that a truck was taking across Manhattan. If you had knowledge of the street grid and the traffic light timings, you could eventually figure out its probable route by measuring the total time of its trip. This isn't because of a particular design feature of trucks, streets, or traffic lights. It only comes up with they're combined into a working system. Similarly, you would expect any truck to be vulnerable, because trucks all have certain things in common (they drive on streets, they have to stop at traffic lights, they're affected by traffic.)

[Jamie Jones]

Order, order!

Intel first said only Broadwell and Haswell CPUs had the problem, but later said its more recent Ivy Bridge, Sandy Bridge, Skylake and Kaby Lake architectures are all misbehaving after patching.

Huh? SandyBridge and Ivy Bridge are older than Broadwell and Haswell

[David Pearce]

It does mean that a new design cpu that is clean for these bugs by design, will be significantly faster than the present offerings. All for no increase in clock or major jump in transistor count

[Luiz Abdala]

If Windows create a section called:

HKEY_LOCAL_MACHINE/(...)/KnownBugsPatched (Boolean)

it's gonna add another 500MB of cruft on Windows Registry, just with descriptions.

Oh wait...

[Alan J. Wylie]

Excellent posting by David Woodhouse

https://lkml.org/lkml/2018/1/22/598

This is an excellent, "must read", summary of the current status.

[Alan J. Wylie]

Re: Excellent posting by David Woodhouse

And kernel documentation from Dan Williams of Intel.

speculation.txt

Note that it's currently v4.1 - use the pull down in the top right to check you are looking at the latest version.

[Tom Paine]

Rumours

Rumours are rife that a generation of products will have to be redesigned, at unknowable expense and delaying next-generations products by un-guessable amounts of time.

Rumours are also rife (well, I've seen a few people say stuff on Twitter. @dakami for instance https://twitter.com/dakami/status/954015056651460609) that Meltdown and Spectre are really just the first of an entire class of vulnerabilities in current CPU architectures and there's a lot more of this sort of caper to come this year.

Whoo. yeaah. yippee.

[hellwig]

the original cabal that nutted out a response

Does nutted mean something different on your side of the pond? Or is this being read as intended by my US eyes?

[kneedragon]

Well that was fun. I just got an Intel firmware update, on my 6700, through Linux Mint (who did not write it, I'm sure of that) and now the machine seems to be bricked. I'm typing this from the wife's win10 laptop. Now I've got to explain to her that it wasn't Linux (or Mint) who fuct-tup, it was Intel. I don't think that's going to be believed somehow...

[wownwow]

According to the Intel CPU design, the White House (Kernel) need to relocated for the security issue (Meltdown)!

According to Intel CEO, relocating the White House is the intended design (with no privilege level checking)!

So far, Intel isn't liable for INTENTIONALLY selling the faulty (not checking and not correctly handling the privilege level) CPU chips designed basing on the specifications with the INTENDED flaw of the privilege level handling, unbelievable and amazing!!!

[Anonymous Coward]

Stop it, just, Stop!

NO one will EVER see these succeed in the wild so can we stop making this into a worse Drama?!

You either belong to the...

a- Sensible people group that will patch because they can't afford the risk

or

b- People that understand BS and have rated this "threat" as moderate to low

[JeffyPoooh]

Suggestion: The Art of War

Boffins looking to prevent or mitigate these vulnerabilities while minimizing the impact on performance may wish to consider an 'The Art of War' approach.

Instead of preventing the information from leaking, let it leak. Just randomize the leakage - somehow.

I acknowledge that this is conceptual *in the extreme*.

[teknopaul]

Live by the sword

Oracle, for one, is furious it wasn’t immediately invited to the top table

Was it expecting the invite from Google or RedHat?

[Anonymous Coward]

Whoever wrote that rubbish grep command in the article...

...clearly came from a Windows background. LOL.

[Anonymous Coward]

Re: Whoever wrote that rubbish grep command in the article...

Indeed. I can only assume the author was lamentably unaware of "cat"?

[Simon Wynn]

Motherboard Fixes

To fix the Meltdown issue on my PC a motherboard BIOS update is required before the Windows 10 patch will apply.

I've never tried a BIOS update before and not keen on the idea of potentially bricking my PC. Can't see a majority of home users applying these types of update.

Won't this leave a large number of older PCs open to Meltdown exploits?

[xenny]

Re: Motherboard Fixes

Are you certain?/Do you have a link? The BIOS updates are typically for Spectre mitigation.

All the meltdown patch does is stop mapping the kernel into each application's address space.

The BIOS updates contain fresh microcode to allow finer control of branch prediction to make Spectre mitigation easer.

[Simon Wynn]

Re: Motherboard Fixes

You're right, I don't know my Meltdown from my Spectre.

Double checking my PC shows the Meltdown fix is applied, but a full Spectre patch requires the BIOS update.

[xenny]

Re: Motherboard Fixes

If it's any reassurance, I've just done several hundred, deploying the initial Intel microcode and then rolling it back as they've acknowledged it is buggy.

I'd suggest waiting until you've got a BIOS release with the final microcode, and then it should be plain sailing....

[unicomp21]

Howto truly fix Spectre and Meltdown

Isn't the solution to this big mess pretty simple? Why not just use bare-metal servers which one controls 100%?