Waited For the 2017 Processors is it broke ?

[noteple]

Debian Linux reveals Intel Skylake and Kaby Lake processors have broken hyper-threading zd.net/2tdeofm via @ZDNet
The latest Intel chips have a nasty bug that causes unpredictable system behavior.

 

[Ries]

Debian Linux reveals Intel Skylake and Kaby Lake processors have broken hyper-threading zd.net/2tdeofm via @ZDNet
The latest Intel chips have a nasty bug that causes unpredictable system behavior.

They have a flaw, but it's fixable with a microcode update. If the update will have any drawbacks is still unknown.

 

[noteple]

Has Apple ever rolled out a processor microcode patch that is user installed?
Or is this something that would be a recall ?

 

[Strelok]

My question would be, how relevant is this? I heard about microcode issues with AMD's Ryzen as well, but it was mostly limited to Linux. The article said it can affect any operating system, but maybe it's not very likely on macOS/Windows while it's more likely to occur on Linux?

 

[EugW]

Has Apple ever rolled out a processor microcode patch that is user installed?
Or is this something that would be a recall ?

It would be fixed in a firmware update or else in the macOS kernel, from what I gather. So not a big deal.

Plus it would never effect 99% of us anyway.

 

[ChrisKra]

actually you wont notice the firmware update besides a reboot or two.

 

[PieTunes]

Processor errata do happen and for the large majority of users, they're nothing to be concerned about, and nothing to affect your work unless you hit all the criteria to cause the issue, which usually would be extremely rare for most people.

 

[noteple]

So if I understand correctly
Not really an OS X problem
Not likely to see the issue under normal circumstances
Apple will be able to patch around it.

 

[peraspera]

So if I understand correctly
Not really an OS X problem
Not likely to see the issue under normal circumstances
Apple will be able to patch around it.

The bug affects all computers with Intel Skylake and Kaby Lake processors irrespective of OS. It is unlikely that Apple rather than Intel will develop the patch but Apple will nearly certainly offer it to their customers when Intel completes the patch.

The unpatched bug provides a very attractive target for malware exploits. None have surfaced as of yet but it would be naive to think that bad guys aren't working their little black hearts out trying to develop one before Intel completes the patch. Steve Gibson talked about the bug in his Security Now podcast Episode #618 https://www.grc.com/securitynow.htm.

 

[treekram]

So I looked at the transcript of the podcast of "Security Now!" which is referenced in post #9. Their podcast talked about multiple topics, the Skylake/Kaby Lake bug being one of them. They did not mention it as being a security concern. I read the part where they talked about the bug (skimmed the rest) so if I'm missing something, please let me know. The concern of this type of bug would be somebody launching a denial-of-service attack on a computer which has a web presence. I don't think many coders with evil intents dropped what they were doing to work on exploiting this bug. Maybe some coders with mischievous intents would find this interesting.

https://www.grc.com/sn/sn-618.txt

I have a Skylake computer and a website on AWS (who knows if it's running on Skylake or Kaby Lake). This is not something I losing sleep on.

 

[aevan]

I have occasional CPU crash that happens in different apps during sleep sometimes which causes a Kernel panic and a reboot. I attribute this to this bug, so I hope Apple patches in the microcode in next Sierra patch or in High Sierra.

 

[treekram]

I have occasional CPU crash that happens in different apps during sleep sometimes which causes a Kernel panic and a reboot. I attribute this to this bug, so I hope Apple patches in the microcode in next Sierra patch or in High Sierra.

In my opinion, the nature of this bug and what the CPU does going into and coming out of sleep doesn't make it likely that your problems are caused by this bug. You can try this out and disable hyper-threading and see if you have any more issues. If your problem is occasional, the fix may happen before a crash happens again. My guess would be that you will continue to have the same sleep issue after the fix.

 

[peraspera]

So I looked at the transcript of the podcast of "Security Now!" which is referenced in post #9. Their podcast talked about multiple topics, the Skylake/Kaby Lake bug being one of them. They did not mention it as being a security concern. I read the part where they talked about the bug (skimmed the rest) so if I'm missing something, please let me know. The concern of this type of bug would be somebody launching a denial-of-service attack on a computer which has a web presence. I don't think many coders with evil intents dropped what they were doing to work on exploiting this bug. Maybe some coders with mischievous intents would find this interesting.

https://www.grc.com/sn/sn-618.txt

I have a Skylake computer and a website on AWS (who knows if it's running on Skylake or Kaby Lake). This is not something I losing sleep on.

I listened to the podcast live and definitely recall Steve Gibson mentioning the bug as a security vulnerability but he only did so in passing. If the bug didn't pose a security concern Steve would not have covered the issue at all.

Steve did not cover any specifics of how the bug might be exploitable or how easy or difficult it might be to do so and I would doubt that he would discuss this as long as the bug remains unexploited and unpatched. If you contact Steve and ask generally how bugs of this nature are typically exploited and what your level of concern should be he would probably answer that much.

 

[aevan]

In my opinion, the nature of this bug and what the CPU does going into and coming out of sleep doesn't make it likely that your problems are caused by this bug. You can try this out and disable hyper-threading and see if you have any more issues. If your problem is occasional, the fix may happen before a crash happens again. My guess would be that you will continue to have the same sleep issue after the fix.

You base your opinion on what? Ars said that the bug may cause cpu crashes which is always the reason for the restart of my Mac according to reports.

It's hard to test as the issue happens rarely, I would have to run my Mac without hyperthreading for a week to see if it works.

 

[treekram]

I listened to the podcast live and definitely recall Steve Gibson mentioning the bug as a security vulnerability but he only did so in passing. If the bug didn't pose a security concern Steve would not have covered the issue at all.

Steve did not cover any specifics of how the bug might be exploitable or how easy or difficult it might be to do so and I would doubt that he would discuss this as long as the bug remains unexploited and unpatched. If you contact Steve and ask generally how bugs of this nature are typically exploited and what your level of concern should be he would probably answer that much.

I based what I said on what I read in the transcript, which may be edited from the podcast. I'm not the one concerned about this bug being a major security concern. If you disagree with my assessment of the risk, I wouldn't mind being corrected by Steve Gibson but you should be the one contacting him as you're the one who's using him as basis for saying this poses a notable security risk.

You base your opinion on what? Ars said that the bug may cause cpu crashes which is always the reason for the restart of my Mac according to reports.

It's hard to test as the issue happens rarely, I would have to run my Mac without hyperthreading for a week to see if it works.

I haven't programmed for sleep and wake in OSX, but I have in iOS and from the documentation, it's works in a similar fashion. You have to ask the OS for the sleep/wake notification and then code for these notifications. For sleep, you stop any active processes and save state. It's hard to see how the bug affects the preparation for sleep because if there was an issue, it should have happened BEFORE the sleep. The OS will wait until all applications have completed their sleep preparations before doing the work it needs to sleep. Waking is a more chaotic situation than preparing for sleep and on iOS at least, different events don't always occur in the same order and for my app at least, which had to deal with possibly restarting network connections, it was a trial-and-error process as to what worked and what didn't on a consistent basis when dealing with the network connections. What's happening in the waking process is having the CPU restore state for the OS in general and the applications that requested the wake notification. As is the case with my app, there may be the need to get the hardware back in order (so maybe re-opening a file, etc.). From the reading of how the bug works, it appears that it makes intensive use of the registers and requires prolonged use to make it appear. I don't think the type of work done on wake - restoring state and making sure hardware connections are restored, etc., is register intensive and it certainly isn't prolonged. Now, if one has a CPU-intensive process that starts up on wake, that may be a different story but if one can't get that CPU-intensive process to fail when not sleeping, the chances of it failing immediately upon waking seems small to me. Most sleep issues are due to the chaotic nature of wake that I described, especially if you have an app that doesn't ask for sleep/wake notifications or hasn't been tested extensively on the particular hardware/OS one is using.. Also, Apple doesn't have a lot of experience with either the Skylake or Kaby Lake processors used in the MBP, comparatively speaking so there may need to be some tweaking that they need to do as it relates to the sleep/wake process. There's just so many variables in the sleep-wake programming and processing and for me, it just seems that this particular bug should not be on the top of anybody's list as the culprit of sleep-wake issues.

 

[treekram]

There something that Steve Gibson mentioned in his podcast (see post #9) that I didn't understand the full implication of until it had some time to percolate in my brain.

He said that hyper-threading didn't give a great performance advantage, maybe 10%. When I read the transcript yesterday, I thought "I wonder if he's right" but it blew past me. This morning I thought, if he's right, then it shouldn't be a big deal for people who are concerned about this bug to disable hyper-threading. So I tried this out on my 2012 quad-core Mini (the most convenient computer for me to use at this point), doing a HandBrake transcode of a 681MB, 720p video took 11:36 on my Mini with hyper-threading on. With it off, it took 13:37, so there was a 15% performance gain from hyper-threading. A second time the difference was 14%. (I used the Instruments app that comes with Xcode to turn hyper-threading on/off because it's convenient for me and doesn't require a reboot to effect the change.)

So if anybody is concerned about the bug, you're not going to pay a big performance penalty if you turn hyper-threading off, which will prevent the bug from occurring. ~15% is going to be the most one should see. If you only ever require two threads at any one time (4 threads if you have a quad-core computer), you will see no performance penalty. At some point if it's convenient, I'll may this out on my Skylake computer and see if there's any notable difference.

To turn off hyper-threading, from the Terminal, enter sudo nvram SMT=0 (to re-enable, enter sudo nvram -d SMT). The computer has to be re-booted for this to take effect. I haven't tried these commands out - it's what multiple people on the Internet works. If you're having a problem on one of the new 2017 MBP's and think that this bug is causing it and you're going to wait until Apple comes out with the fix, there's a good chance that the fix will come bundled with the next Sierra update. At that point, after you update and if your problem is fixed, you won't know if the Sierra update or the bug fix fixes your issue. And if you don't have a backup of the computer pre-update, you won't be able to revert back to ascertain whether this is true or not as the special Sierra version currently on the new MBP's will disappear once 10.12.6 is released.

So if this bug is bugging you, just turn off hyper-threading and leave the rest of us be.