Intel Says Newer Chips Also Hit by Unwanted Reboots After Patch (zdnet.com)

Intel says the unexpected reboots triggered by patching older chips affected by Meltdown and Spectre are happening to its newer chips, too. From a report: Intel confirmed in an update late Wednesday that not only are its older Broadwell and Haswell chips tripping up on the firmware patches, but newer CPUs through to the latest Kaby Lake chips are too. The firmware updates do protect Intel chips against potential Spectre attacks, but machines with Ivy Bridge, Sandy Bridge, Skylake, and Kaby Lake architecture processors are rebooting more frequently once the firmware has been updated, Intel said. Intel has also updated its original Meltdown-Spectre advisory with a new warning about the stability issues and recommends OEMs and cloud providers test its beta silicon microcode updates before final release. These beta releases, which mitigate the Spectre Variant 2 CVE-2017-5715 attack on CPU speculative execution, will be available next week.

Comments

Enough with the euphenisms

[Anonymous Coward]

These "unwanted reboots" are system crashes.

Re:Enough with the euphenisms

[bazmail]

Indeed, classic corporate sterility. Like saying that homeless man on the street initiated an unwanted surcharge against the man while holding a knife to him.

Re:Enough with the euphenisms

[PingSpike]

Or just standard Windows 10 Update behavior.

Re:Enough with the euphenisms

[Anonymous Coward]

Has anyone read any details about these reboots though? Are we talking spontaneous hard resets? Processors stalling? Data corruption? Or something more like SMM interrupts or other low-level management software running too slowly and missing deadlines?

Re:Enough with the euphenisms

[Anonymous Coward]

Firmware? What is wrong with you? Do you mean microcode?

Re:Enough with the euphenisms

[Anonymous Coward]

LOL. I'm so glad I didn't apply any of these bullshit patches. I kept my performance and don't have stability problems.

I know how to maintain my PCs so the "security" patches are completely unnecessary.

Re:Enough with the euphenisms

[sinij]

Not homeless man, but man from indeterminate address. Also not holding a knife, but presenting coercive evidence.

A person from an indeterminate address initiated an unwanted surcharge against the man while presenting a coercive evidence.

Re:Enough with the euphenisms

[arth1]

These "unwanted reboots" are system crashes.

Or watchdog initiated reboots.

In any case, it's not the CPU or microcode that reboots the machines, but the OS. That is an OS bug, and the Intel/AMD microcode is at most a trigger for the OS not handling conditions correctly.

At any rate, I have not seen a single reboot of any of several dozen Linux machines, so hopefully the OS bugs are Windows and/or MacOS only.

Re:Enough with the euphenisms

[KingMotley]

Uh... No.

The CPU can reboot the machine independent of the OS that is running. There are actually a number of ways of doing this from simply simulating (or being affected as if) power was temporarily removed, to handing off control to the BIOS to do a quick reboot.

Re: Enough with the euphenisms

[GarySalter]

About time that the (writable) microcode ( and the microcode roms (internally), if any, were declared open source, non of this mysterious black box nonsense any more, as all intel/AMD computers now run most everything everywhere, as it is too important to tolerate anymore. These closed boxes of operating systems and closes internal cpu Architectures (and internal closed âsecurityâ(TM) features).

Re:Enough with the euphenisms

[Anonymous Coward]

Indeed, classic corporate sterility. Like saying that homeless man on the street initiated an unwanted surcharge against the man while holding a knife to him.

Great post! The only thing I'd like to point out is that studies have shown that you're between ten and fourteen times more likely to get attacked by the kind of deranged alt-right sexual inadequate that posts on Slashdot, than you are by a homeless person.

Fucking ridiculous

[Anonymous Coward]

Come on.

Don't worry folks

[Thruen]

You won't even notice the effects of the patch.

Re:Don't worry folks

[Matt.Battey]

So my father-in-law has his Windows 8 box set for automatic updates. Last week he hit a web site that was telling him to call Microsoft Customer Support at (800)ITS-SCAM (not the real number, and he called me first and didn't go through with it).

He checked the updates and made sure they were applied, now his computer does nothing but reboot. Is this the symptom they are talking about? Does it require a re-install of the OS to fix, or is it bricked?

Re:Don't worry folks

[Thruen]

I can't claim to be an expert, but I'd say try to roll back to before the updates if you can. If that doesn't work I would probably re-install Windows. If it's trying to boot but just keeps restarting it shouldn't be bricked, so a re-install should get it booting again in any case. Just be careful not to automatically update again after the re-install!

Re:Don't worry folks

[HiThere]

Well, it's clearly not bricked, but my inclination would be to install debian mate on the machine. After making good backups. And it sounds like you need to boot from a live-cd to even make backups.

OTOH, some people have said that after several re-boots the system settles down. Wouldn't know myself, as I don't do Windows.

Is it an AMD box or an Intel box? If it's AMD, then you're probably safe just rolling back the upgrade (can you?). Spectre isn't anywhere nearly as dangerous as Meltdown...yet.

O, and bricked means the machine won't reboot without a hardware intervention...and not just the power switch. It basically means the machines new highest use is as a doorstop, but that's usually been hyperbole.

Re: Don't worry folks

[Matt.Battey]

OK, is see. So these updated don't change the BIOS? When they're talking about microcode updates, that's code loaded into the CPU when the OS is loading, not something more permanent?

Re: Don't worry folks

[Anonymous Coward]

Microcode updates are loaded when the OS is loading, so they are not permanent. Why microcode updates via OS and not the BIOS (firmware update)? Well, because it's harder to push motherboard manufacturer/BIOS provider to update the firmware, also it's manual (users need to update the BIOS firmware themselves). It's easier via OS, it's automatic.

Re: Don't worry folks

[Anonymous Coward]

Wrong. Microcode updates are applied by flashing an updated BIOS firmware, which can be done by the OS.

Are they working on new chips?

[jfdavis668]

Is Intel developing new chips that don't have this problem? Are they going to be slower, too?

Re:Are they working on new chips?

[Anonymous Coward]

silicon is planned years in advance
they are certainly working on new chips without these flaws but you won't see them until 2020 earliest

Re:Are they working on new chips?

[AvitarX]

Almost certainly planning them, and they will be faster than current chips (progress and all that).

Im curious how much of a speed Improvement they got for the design decisions that left them vulnerable to meltdown though.

It looks like a 5-10% cost to mitigate in software, probably less than in hardware.

AMDs chips mitigate meltdown in hardware, is that part of the performance gap?

Re:Are they working on new chips?

[Anonymous Coward]

"AMDs chips mitigate meltdown in hardware, is that part of the performance gap?"

was wondering the same thing myself.

Re:Are they working on new chips?

[EndlessNameless]

Is Intel developing new chips that don't have this problem?

Of course, but the lead time on CPU development is long. It will be at least a year or two before consumers can buy anything with builtin resistance to Spectre and Meltdown.

Are they going to be slower, too?

The generational improvements will probably offset the losses, so I strongly doubt that will be the case.

Plus, fixed CPUs will not require KPTI anymore, so they will be secure with the "normal" OS-level performance optimizations. Windows and Linux can go back to doing things the pre-Meltdown way if Intel fully addresses their problems.

Re:Are they working on new chips?

[Anonymous Coward]

The truth is that Meltdown is a patented Intel(TM) only spying method (or almost, but AMD got it right on all its x86 implementations).
More seriously, it is delaying the check for access violation well past the point of no return (from an exploit point of view), it is probably fairly cheap to correct the hardware: you have to go through the TLBs to translate the access from virtual address to physical (and even more complex in a virtual machine), this means matching 36 bits (for current 48 bit virtual addresses, 9 more bits with 5 level page tables), moving back the logic to check for access violation to be simultaneous with the translation or cache access (where it belongs) is not trivial, but a competent team could probably do it in a few weeks (the issue is that the HDL code dates from the PPro, and it may be a black box that nobody understands anymore). It's only a few bits to check in the TLB entry (along the bits that define memory attributes cacheable). The influence on the transistor bugdet, processor frequency, performance, and power consumption is probably not measurable. Meltdown is simply a side channel of excessively optimistic execution past a point which would always result in an access violation.
While they are at it, an access violation should always end up in a page table walk, reloading the TLB entry, otherwise this is a side channel which may indicate the kernel mappings to an attacker. This would also get rid of some cases of spurious access violation: the kernel does not invalidate page tables when it relaxes access permission to a table, another thread which has this page cached actually incurs a useless page fault in which the kernel simply invalidates the offending TLB entry so that it is reloaded after the exception routine terminates.

Now Spectre is another matter, it means basically a complete redesign of the branch prediction logic, which often skimps on the number of address bits used to address the associated caches. One solution is to make a full address match, including address spaces, but I'm not even sure that it would be 100% tight.

Re:Are they working on new chips?

[Anonymous Coward]

AMD doesn't mitigate Meltdown. The problem simply doesn't exist in AMD chips. I don't think that it has anything to do with AMD being faster, since previously AMD's CPUs were slower than Intel's.

Re:Are they working on new chips?

[Anonymous Coward]

Given failure to move on from 14nm and early reports on their 10nm process showing it performing worse, it's unlikely that any architectural improvements will overcome the 5+% performance hit of meltdown avoidance. Its hard to see any performance increase between skylake and coffee lake, and it's likely that the jump between haswell and the more recent processors was just the process change plus ddr4 support.

Re:Are they working on new chips?

[AvitarX]

I guess prevent is a better word, but the checks that AMD does in hardware prevents meltdown. Does that check have overhead? If so how much? It follows that some of the speed difference is because of this overhead if there is overhead.

Clearly AMD had other problems with their design that made them slower for a very long time, but how much was because they were immune from meltdown?

Re:Are they working on new chips?

[AvitarX]

Thank you for that great response.

How much of Spectre can be mitigated by coding while mindful of it? At what cost?

I guess what I'm saying is leaving the vulnerability and trusting coders a valid choice (that's how buffer overflow was for a while if my understanding serves, then later additional instructions were added that made them less damaging?)

Re:Are they working on new chips?

[Anonymous Coward]

Common sense would say that they are already working on this, and also on a better interface for disabling/enabling processor features as to avoid the huge problems in patching all of this stuff.
If FUCKWIT can be reverted, much of the performance hit will go away and things will steer back to normal.

BUT... then again, Common Sense is not a corporate best practice.

Re:Are they working on new chips?

[arth1]

How much of Spectre can be mitigated by coding while mindful of it? At what cost?

Pretty much all of it can be prevented. But you have to identify the problem areas in the source code, change it, and recompile, for all software on the system, including OS utilities and userland drivers.
So in practice, that's not going to happen.

Re:Are they working on new chips?

[AvitarX]

How is this different than a buffer overflow? that it can be down in all languages?

Isn't the fixing of buffer overflows a similar situation?

Re:Are they working on new chips?

[arth1]

How is this different than a buffer overflow? that it can be down in all languages?

Isn't the fixing of buffer overflows a similar situation?

It's quite different, alas.

An example (if I understand this correctly, which may not be the case):

volatile char *bar;
char *foo = somesharedaddress;
if foo[0] {
    bar=foo[0];
} else {
    bar = NULL;
}
Here, bar might temporarily be set to foo[0] due to a speculative prediction that foo[0] is non-zero. Other threads with access might, if the timing is right, see the speculative value.
The fix is to move the value first, before testing.

I.e. the code isn't doing anything wrong, like with a buffer overflow. The CPU is.

Re:Are they working on new chips?

[AvitarX]

What I mean is how is the mitigation by programming different.

All software, even the OS, had to be patched, all cases found and fixed, mindfulness in future programming etc. Etc.

Eventually, over time, hardware and carefulness, and using different languages, and new features of the same languages, they're almost a thing of the past (relative to the time that a long URL could cause one).

Sure, hardware helps mitigate when an overflow happens now (64 bit address space with address randomization for example), but fundamentally it was a programming fix.

With spectre, the issue (again as I've understood, I can only read analysis, not the details) is that a process can read any of it's own memory, it seems credible that tools can be developed to try and find instances in code, language features can be developed to compile in a way that prevents it, etc. Etc.

Like with buffer overflows, I assume the programming side will address it faster than hardware can.

Obviously the exploit is different than a buffer overflow.

Re:Are they working on new chips?

[AvitarX]

Ignore me, I missed your last paragraph, sorry.

I think what you're saying is that it's hard to detect because it's all proper from the code side?

Re:Are they working on new chips?

[Anonymous Coward]

The generational improvements will probably offset the losses

What generational improvements? In case you hadn't noticed, single-core CPU performance has pretty much stalled for the past five years. CPUs have gotten cheaper, they've gotten more power-efficient, they've gained lots more pins, core counts have gone up, but they haven't gotten faster.

Re:Are they working on new chips?

[Anonymous Coward]

"AMDs chips mitigate meltdown in hardware, is that part of the performance gap?"

Possible, hard to tell, depends on how expensive the security check is.

I just hope that Intel learns their lesson and implements a positive security model (like AMD), rather than just expanding their current negative security model to close this particular issue.

Re:Are they working on new chips?

[Anonymous Coward]

So they toss an extra ultra low power core in there that is dedicated to handling Meltdown and Spectre. Problem solved.

Or they could revive Larrabee and start producing CPUs with hundreds of cores based on the Pentium, which doesn't have speculative execution and is therefore immune to Meltdown and Spectre while still being faster than anything out now.

Oh, well that's nice

[Anonymous Coward]

I put the chances of people installing these patches between zero and "snowball's chance in hell."

Reports of reboots from patch vastly overstated

[JoeyRox]

I updated my machine and haven't had a single r

Re:Reports of reboots from patch vastly overstated

[Anonymous Coward]

You forgot to add the obligatory NO CARRIER to your joke.

Re:Reports of reboots from patch vastly overstated

[Khashishi]

Only old people add NO CARRIER to their jokes.

Re:Reports of reboots from patch vastly overstated

[Anonymous Coward]

Even millennials were alive when modems existed. Hello!

Re:Reports of reboots from patch vastly overstated

[Anonymous Coward]

Many millennials are like 40 years old now, so we qualify as "old".

I was born in the late 70s so I am part of Generation Y (millennial generation).

Rebooting more frequently?

[rsilvergun]

is that some kind of euphemism for a blue screen or bricking?

Re:Rebooting more frequently?

[kelemvor4]

is that some kind of euphemism for a blue screen or bricking?

yes

Re:Rebooting more frequently?

[thegreatbob]

Yes.

Re:Rebooting more frequently?

[Anonymous Coward]

is that some kind of euphemism for a blue screen or bricking?

Not really.

Blue screen is unique to Windows. Bricking implies permanent death of the hardware.

Think of it as more along the lines of "random reboots caused by newly introduced system instability due to a patch which was rushed out the door to address a fundamental hardware defect".

This has basically pulled the rug out of pretty much every OS on the planet, and it sounds like the 'fix' introduces a new set of issues.

Re:Rebooting more frequently?

[Anonymous Coward]

Except that Windows doesn't have a BSOD but rather just silently reboots whenever there is a crash. So yes, rebooting = blue screen in modern versions of Windows, which presumably includes server versions as well.

Re:Rebooting more frequently?

[arth1]

Except that Windows doesn't have a BSOD but rather just silently reboots whenever there is a crash. So yes, rebooting = blue screen in modern versions of Windows, which presumably includes server versions as well.

Go to System Properties, Advanced, Startup and Recovery, and under System Failure, uncheck "Automatically restart".

You should now be able to tell the difference between a BSOD and a reboot done for other reasons.

Windows? Linux? Mac?

[Anonymous Coward]

Can you be more specific? Which OSes are rebooting?

Re:Intel's days are numbered

[Anonymous Coward]

Um... What language was that? I even tried creimer-to-English and it didn't work.

What are you trying to say?

Re:Intel's days are numbered

[Megol]

I think it should be "I think their stock price may halve every 18 months"?
Not that likely even if they are exposed as reptilians eating small (but tasty) children.

Intel Unsafe and Insecure at Any Speed

[Anonymous Coward]

Intel engineers need to learn that you don't get extra credit for arriving at the wrong answer faster than someone who gets the correct answer, but slower and safer, and without rebooting 3 times.

Re:Intel Unsafe and Insecure at Any Speed

[DontBeAMoran]

Remember Texas Instruments? They were the first ones to sell solar-powered pocket calculators so they know how to compute correct answers at low power. Let's have them make processors!

Remember Casio? They were the first ones to sell digital watches, which is a pretty neat idea, with built-in calculators that could compute correct answers. Let's have them make processors!

What other CPU was not affected by those flaws? Atmel's ATmega series. Let's have them make processors!

Re: Intel Unsafe and Insecure at Any Speed

[Anonymous Coward]

AMD is unaffected by Meltdown.
Meltdown is a severe risk.

No one cares about other trivial in comparison issues that might be a "Not Just Intel" problem.

Re: Intel Unsafe and Insecure at Any Speed

[DontBeAMoran]

AMD seems to be affected by everything else apart from Meltdown, that's still security risks in trade-off for speed.

Re: Intel Unsafe and Insecure at Any Speed

[Brockmire]

Atmel fucks up their chips regularly, including brown out bugs that last years through multiple designs. Ran into three wtf's when doing stuff with last Atmel project. You have to read forums for solutions and workarounds.

Re:Intel's days are numbered

[kelemvor4]

I think they're stock price may have every 18 months.

and then you can't even?

What patch?

[Anonymous Coward]

I've have an Ivy Bridge that's just outside their window for microcode updates. Guess I'm on my own, Intel.

Re:Windows? Linux? Mac?

[DontBeAMoran]

Which OSes are rebooting?

yes

Re:Windows? Linux? Mac?

[The123king]

All of them

Hardware now faulting, hello warranty.

[Fly Swatter]

If it used to work without 'reboots', and now it is failing within the hardware, is this not a defect under warranty? Not that they would have a 'working' replacement at this point.

Yes I read Intels warranty, and they will deny you, but in theory this is no longer an errata and plain old defective behavior until they release an update to mitigate the failure caused by the vulnerability mitigation.

Quite frankly Intel is trying to get something out way too fast, and is looking even worse for it.

Re:Hardware now faulting, hello warranty.

[AmiMoJo]

Depends on where you live I guess. In the UK they have a "reasonable length of time" to fix warranty issues before you can get a refund or replacement. That's usually considered to be 28 days.

I guess the question is when does the 28 days start? It's from when you contact them about the issue. I contacted them as soon as I read about the flaw a few weeks ago, and they haven't delivered a working fix for it yet.

Re:Hardware now faulting, hello warranty.

[raburton]

Problem is if they can't fix it in a reasonable time period they can't replace it with a working chip either. As far as I have read so far all their modern chips are affected, new chips with a proper hardware fix don't exist yet. I guess that still leaves the refund route, then you can buy an AMD - not perfect but seems better. In the UK you have up to 6 years warranty. Although the onus is on the purchaser to prove the fault is a result of an inherent defect, which is usually difficult, that won't be hard in this case since Intel has, eventually, admitted it themselves.

Re:Hardware now faulting, hello warranty.

[AmiMoJo]

The problem with the refund route is that a lot of your other hardware probably depends on the CPU, e.g. the motherboard won't take a newer Intel CPU let alone an AMD one.

In this case I think normal consumer laws are not going to be enough to sort it out, and I'll end up in Small Claims Court with them. Currently their engineers are looking at my situation to see if they can suggest anything, but I doubt it. I mean, if they could then they would have already told the people running thousands of servers and seeing massive performance hits about it.

Re:Hardware now faulting, hello warranty.

[Anonymous Coward]

I bought 3 Dell Latitudes last summer -- when I first got them, I turned off the feature that blocks bios updates from OS update screens -- if these ever start failing due to the Intel issue, I'll return all 3 back to Dell and let them deal with Intel

Re:Hardware now faulting, hello warranty.

[DigiShaman]

The Intel CPU is working as expected in terms of performance. Security was never part of the equation unless specified in the marketing material. The real fucking irony here is that it's the actual fix, the microcode patch, that could allow for claiming "faulty hardware". So, the patch is to un-patch the CPU.

What fucking universe did I wake up too? Intel was like the motherfucking GOLD STANDARD of CPUs. Not any more. Fine, AMD it is from now on

Re:Hardware now faulting, hello warranty.

[Cederic]

Or you could accept that you bought a specific class of CPU that offered published performance characteristics, and it continues to provide those.

If you choose to cripple it by running non-performant software that's hardly the vendor's issue.

Re:Hardware now faulting, hello warranty.

[thegarbz]

What is warranty other than the vendor will provide you something working. Yes it is a warranty claim. The fix to the claim is not to send your stuff in, but rather to update the firmware.

Hopefully just reboots

[CustomSolvers2]

If my brand new computer gets damaged in any way because of this, I would be quite upset. Actually, if I could choose, I wouldn't even install the patch. I understand that hardware vendors have to account for any the possible scenario (mainly after having got so much advertisement!), but seriously doubt that anything of this will ever affect me.

Re:Hopefully just reboots

[jittles]

If my brand new computer gets damaged in any way because of this, I would be quite upset. Actually, if I could choose, I wouldn't even install the patch. I understand that hardware vendors have to account for any the possible scenario (mainly after having got so much advertisement!), but seriously doubt that anything of this will ever affect me.

This is a microcode update and, therefore, will not happen on your machine unless you update your bios. Of course, Apple includes UEFI updates in their releases so, you may or may not have the option to withhold this patch

Re:Hopefully just reboots

[CustomSolvers2]

will not happen on your machine unless you update your bios. Of course, Apple

OK. I am not too sure about how my current operating system (Ubuntu) and computer (no brand, just different parts put together) deal with BIOS updates. In principle, it should be done manually or by showing a very clear warning + me having the last word, but who knows for sure? Anyway and as said, in case of being able to choose, I wouldn't install it.

Re:Hopefully just reboots

[CustomSolvers2]

PS: I have never used Apple products myself (and bear in mind that I am a programmer who has developed software under many different conditions with caring too much about specific environments, but who happen to have never dealt with Apple-related anything!), apparently they only have 8% of desktop market share and, although there is a relevant number of Apple-related articles here lately, the Slashdot crowd seems to be mostly focused on Linux (or even Windows before Apple). Why even mentioning Apple under a priori so Apple-unfriendly conditions? Please, don't take this comment bad, I am just highlighting an issue which I found quite curious.

Re:Hopefully just reboots

[CustomSolvers2]

My "with caring too much" should be understood as "without caring too much".

Re:Hopefully just reboots

[CustomSolvers2]

I have never used Apple products myself

Actually, this statement isn't completely true. I did have an iPod for a while, but then I moved to iPud (or whatever the name, a crappy brand poorly emulating iPod) and later to nothing (= hearing music on my computer, phone or similar).

Re:Hopefully just reboots

[jittles]

PS: I have never used Apple products myself (and bear in mind that I am a programmer who has developed software under many different conditions with caring too much about specific environments, but who happen to have never dealt with Apple-related anything!), apparently they only have 8% of desktop market share and, although there is a relevant number of Apple-related articles here lately, the Slashdot crowd seems to be mostly focused on Linux (or even Windows before Apple). Why even mentioning Apple under a priori so Apple-unfriendly conditions? Please, don't take this comment bad, I am just highlighting an issue which I found quite curious.

I mentioned Apple because, to my knowledge, they are the only manufacturer that automatically pushes BIOS updates down to any machine. If you custom built the hardware and are running Ubuntu, you do not have to worry about automatically getting the microcode update from Intel.

Re:Hopefully just reboots

[CustomSolvers2]

custom built the hardware and are running Ubuntu, you do not have to worry about automatically getting the microcode update from Intel.

OK. Thanks for the info.

Re:Intel's days are numbered

[bazmail]

I am shit at typing, although not bad at spelling. Carry on.

Re:Windows? Linux? Mac?

[Anonymous Coward]

I suspect you need to use memory protection, multitasking or at least some separation between user space and kernel memory for the problem to be relevant.

Shouldn't Windows 3.11 or earlier be spared?

Well...

[Anonymous Coward]

rebooting often *is* an effective protection against Spectre and Meltdown: the caches and branch predictors get cleared at reboot, no?

Re:Intel's days are numbered

[Anonymous Coward]

Well, thats odd, isn't it?

beta next week?? what about AMD installed next wee

[Joe_Dragon]

beta next week?? what about AMD installed next week intel?? and I want a refund for your POS cpu.

Re:Intel's days are numbered

[Anonymous Coward]

you mispelled 'their'

No crashes here

[NettiWelho]

[..] but machines with Ivy Bridge, Sandy Bridge, Skylake, and Kaby Lake architecture processors are rebooting more frequently once the firmware has been updated [..]

How can you tell? The patch just got out..

I guess this isn't universal, my 2011 sandy bridge system (windows 7) has been running over 7 days since patching without "reboot" or crash and the patch isn't that old yet..

Re:No crashes here

[Anonymous Coward]

What

Re:No crashes here

[Anonymous Coward]

It's the 20180108 microcode update, so 10 days worth of reports that it's borked. And probably longer for whoever had the opportunity to beta test it before Wintel made it public.

Re:No crashes here

[Anonymous Coward]

Did you Sandy Bridge system even get the bios/microcode update? Most board makers have decided SB's are end of life, and intel wouldn't even make a video driver for the embedded video for windows 10. My Westmere-ep system didn't have issues but it also didn't get any firmware/microcode patches.

Not just the CPU rebooting !!

[ripvlan]

My SSD isn't getting along either. Since applying all of the Windows 10 (and Dell firmware) patches - my disk I/O occasionally jumps to 100% with no process (in perfmon) attributed to the activity. All apps attempting IO along with Windows appears to freeze for several minutes before returning to normal- the OS issues an IO reset (GUI only apps continue to paint and work during this time). BUT -- once in awhile I get a BSOD HW failure to go along with it.

Okay - could be failing SSD on a 8mo old laptop - virus software incompatible or... (insert something else). However, the timing is suspicious.

Re:Not just the CPU rebooting !!

[DigiShaman]

I have a Dell Latitude with a SATA SSD in it running Win10 Pro. It's always been running just fine with BitLocker enabled. Since the Meltdown OS patch, I've had corrupted data that hose the OS from booting. Not even a repair with the recovery partition or automated OS repair processes could fix. I had a backup, so I'm good there.

Long story short, the Samsung 850 Pro was error free and had the latest firmware. Even the Dell ePSA boot diags test reports good hardware. I strongly suspect this patch fucked with Disk I/O write-backs corrupting data back to the disk. Mind you, I haven't even applied the latest BIOS update yet as it wont be available from Dell until Feb 2018. ...this shitshow from Intel continues.

Re:Not just the CPU rebooting !!

[Anonymous Coward]

The meltdown mitigation requires patching how system calls happen. Because of this, it's going to severely slow down disk and network I/O. If you have a high end SSD, it's going to go slower now. For every write or read that your computer does, a system call is done in the kernel to talk to the hardware. This can no longer run at pre meltdown speeds.

Your SSD is fine. Your CPU and OS are not.

Solution is simple...

[GerryGilmore]

... do not apply any of the "patches" or new firmware! A little perspective can go a long way here and unless you have a hosted data center where you MUST be current for legal liability reasons, anyone applying these fixes deserve what they get. The chances of this vulnerability (as opposed to the 94 quadrillion viruses, etc already out there) affecting you are so small as to be ridiculous for you to do anything to mitigate. Much less tampering with the entire, delicately balanced ecosystem of mobos, OSes, etc.

Re:Solution is simple...

[thegarbz]

anyone applying these fixes deserve what they get

Security?

Re:Solution is simple...

[Anonymous Coward]

Yes,, this is an option, as long as you never run any untrusted code, in particular block all Javascipt unless you have personally vetted it. Probably means you web access is crippled but hey, whatever. Meanwhile, in the real world...

Wew

[Anonymous Coward]

Government backdoors are trapped, eh?

Re:Intel's days are numbered

[toonces33]

New version of "Moore's Law".

Responsible disclosure

[FeelGood314]

This was a complicated bug. I can definitely see how the engineers made the design decisions that lead to it. Intel isn't handling this well but if we just consider the patches they are rushed. A few more months would definitely have been helpful. These bugs aren't that bad for home users that don't enable javascript by default. The bad guy still has to get you to run the malicious code. The defects are however devastating for cloud computing where the vendors are running someone else's code.

Re:Responsible disclosure

[evil_core]

OMG, "These bugs aren't that bad for home users that don't enable javascript by defaul"
Do you really believe that 1st thing that typical home user do is to rush to browser setting to disable JavaScript? Or installs NoScript?
I wonder in what world are you living....(and I don't remember any mainstream Web Browser that supported Javascript, but got it disabled by default)

Re:Responsible disclosure

[HatofPig]

I think parent is talking to us, not general home users. They're hosed.

I have the true fix

[slashmydots]

Stop putting stupid bullshit on the chip like powered-off remote controls and speculative energy-wasting and just make them do math.

Re:I have the true fix

[Zuriel]

We have chips that don't do "speculative energy wasting". People don't use them in desktops because they're really slow.

Half baked fixes

[Anonymous Coward]

Trouble is, Intel and everyone else was in such a panic after the public release of these double threats. That they obviously were not in a position to properly test these fixes before a release to public. Its pretty obvious to me that they were still not ready for prime time. But in testing on two separate Kaby Lake systems I have found no such issues with the firmware updates, or the Windows patches. So the issues are affecting certain systems and most likely certain bios configurations. Its a deep core fix so its expected to see some of these problems. Especially when they were rushed out.

Re:Intel's days are numbered

[Anonymous Coward]

I think they're stock price may have every 18 months.

Parse error in statement.

Apparently, you didn't actually think, at least not when you wrote that nonsense.

Re:Intel's days are numbered

[HiThere]

Actually, it's quite parseable if you enable homonym detection. I suspect, however, that it's quite wrong. Were I moderating, I'd be inclined to rate it funny.

Re:Intel's days are numbered

[DigiShaman]

If it's a quantum CPU, it's both odd and even!

Re:Windows? Linux? Mac?

[arth1]

All of them

In my experience, this is not the case.
When using a Linux kernel that does have support for temperature monitoring and processor states for the CPU it runs on, I can't get machines to reboot at all with the microcode updates no matter how hard I tax the systems. They run slower, and turbo mode is affected, but no reboots in any of several dozen systems with different newer CPUs.

Deus Ex

[nehumanuscrede]

I believe was the game where they intentionally borked all the cybernetic implants to force folks to install the update / patch.

Which they then used to create mass havoc.

lol

Think I'll forgo the patch for now.

Re:Deus Ex

[Anonymous Coward]

if you dont patch then your fight against namir becomes too easy with augmentations, you just need to catch him with 2 typhoons and he is dead. You should apply the patch dude, its more interesting that way (and you will also be safer from those pesky russians and that kaspersky supervillain dude)

Re:Intel's days are numbered

[Anonymous Coward]

OK, I give up. Even with the homonym fixed, what does “I think their stock price may have every 18 month” actually mean?

Re:Intel's days are numbered

[HiThere]

"have" is a homonym for "halve", i.e., be divided in half. I usually try to pronounce if slightly differently, if I choose to use it, but I believe that to actually be as incorrect as pronouncing the "t" in "often".

Insufficient management

[Futurepower(R)]

Intel and Microsoft are apparently suffering from the symptoms of years of insufficient management.

A Slashdot comment of mine from 11 1/2 years ago: More Intel employees should say in public what they have told me in private: Intel CEO Paul Otellini is not a competent leader. He lacks social ability.

We no longer have a Windows OS we can trust: Windows 10 is possibly the worst spyware ever made. And: 7 ways Windows 10 pushes ads at you...

We no longer have Intel CPUs we can trust: We translated Intel's crap attempt to spin its way out of CPU security bug PR nightmare.

No crashes here, either.

[bdwoolman]

Dell had an updated BIOS ready on the 10th of Jan. Intel® Core i3-6098P Processor -- Skylake

Re: Reports of reboots from patch vastly overstate

[Brockmire]

No, not in the 70's. Try 80's or later. Fuck the small percentage of those who count the 70's. https://en.m.wikipedia.org/wik...

Re: Reports of reboots from patch vastly overstate

[Anonymous Coward]

What, says the guy who posts a link to the mobile version of Wikipedia?