Intel Says Newer Chips Also Hit by Unwanted Reboots After Patch (zdnet.com) 115
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.
Enough with the euphenisms (Score:5, Insightful)
These "unwanted reboots" are system crashes.
Re: (Score:3)
Re: (Score:3)
A person from an indeterminate address initiated an unwanted surcharge against the man while presenting a coercive evidence.
Re: (Score:3)
Or just standard Windows 10 Update behavior.
Insufficient management (Score:2)
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. [slashdot.org]
We no longer have a Windows OS we can trust: Windows 10 is possibly the worst spyware ever made. [networkworld.com] And: 7 ways Windows 10 pushes ads at you... [pcworld.com]
We no longer have Intel CPUs we can trust: We translated Intel [theregister.co.uk]
No crashes here (Score:2)
[..] 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..
No crashes here, either. (Score:2)
Re: (Score:2)
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: (Score:2)
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 (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
New version of "Moore's Law".
Re: (Score:3)
Re:Intel's days are numbered (Score:5, Funny)
I think they're stock price may have every 18 months.
and then you can't even?
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
"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".
Don't worry folks (Score:4, Funny)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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 b
Re: Don't worry folks (Score:2)
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?
Are they working on new chips? (Score:3)
Re: (Score:1)
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? (Score:5, Informative)
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: (Score:1)
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: (Score:2)
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: (Score:1)
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: (Score:2)
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 bu
Re: (Score:1)
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), bu
Re: (Score:1)
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: (Score:2)
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? (Score:4, Informative)
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.
Reports of reboots from patch vastly overstated (Score:5, Funny)
Re: (Score:2)
Only old people add NO CARRIER to their jokes.
Re: Reports of reboots from patch vastly overstate (Score:2)
Rebooting more frequently? (Score:1)
Re: (Score:3)
is that some kind of euphemism for a blue screen or bricking?
yes
Re: (Score:1)
Re: (Score:2)
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? (Score:4, Interesting)
Can you be more specific? Which OSes are rebooting?
Re: (Score:2)
yes
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
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 (Score:2)
Hardware now faulting, hello warranty. (Score:5, Interesting)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 [netmarketshare.com] 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: (Score:2)
beta next week?? what about AMD installed next wee (Score:2)
beta next week?? what about AMD installed next week intel?? and I want a refund for your POS cpu.
Not just the CPU rebooting !! (Score:2)
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 -
Re: (Score:2)
Solution is simple... (Score:5, Insightful)
Re: (Score:2)
anyone applying these fixes deserve what they get
Security?
Responsible disclosure (Score:2)
Re: (Score:1)
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: (Score:2)
I have the true fix (Score:2)
Re: (Score:2)
Deus Ex (Score:2)
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.