TheRacerMaster Posted February 8, 2018 Share Posted February 8, 2018 AFAIK macOS doesn't have microcode update functionality, Apple just updates the firmware. Link to comment Share on other sites More sharing options...
apianti Posted February 8, 2018 Author Share Posted February 8, 2018 The microcode updates are causing reboot issues and general non-sense, Linux distributions have stopped loading the updates because they are trash. Linus even chastised them for putting such a {censored}show out. Also the microcode updates are only to mitigate the performance hit caused by having to separate the memory spaces and the overhead of switching contexts between them. The problem is in the design of the pipeline of the CPU, even the microcode is executed in the pipeline of the CPU. Basically microcode adds new instructions, that are then atomically executed using other instructions that already exist. There are some new MSRs to control branch prediction and there may be a new instruction for pre-haswell to add to PCID to invalidate the context(s). Microsoft has told OEMs to fix the problem so most likely newer mobos will get an update with a microcode fix, older mobos probably will not. And only Linux will load the most up to date microcode like it always has, that is if they don't decide that it's causing more issues than helping because if you read any of Linus' comments about this, he is not happy about any of it, how it was disclosed, handled, attempted to be fixed, and Intel's complete lack of pretty much doing anything. Also where's AMD? They have these problems too, but they are skating by because Intels are so much worse, and AMD at least attempted to change their pipeline after having such a failure before, hence ryzen. Unfortunately they did not remove the SPECTRE vulnerabilities, lol... EDIT: Oops, sorry, didn't even answer the question. Yes, Apple uses firmware updates for microcode updates. Link to comment Share on other sites More sharing options...
maxb2000 Posted February 8, 2018 Share Posted February 8, 2018 Intel released some patches now for Skylake CPUs: https://www.engadget.com/2018/02/08/intel-spectre-cpu-patch/ and said that patch is coming for older gen CPUs. I wonder if my Haswell setup will get any UEFI updates.. Link to comment Share on other sites More sharing options...
frankiee Posted February 8, 2018 Share Posted February 8, 2018 EDIT: Oops, sorry, didn't even answer the question. Yes, Apple uses firmware updates for microcode updates. So that would mean that Hacks are left with open vulnerabilities where a microcode update is needed to fix or at least mitigate the problem? Which brings me to the point I made some time ago in the Clover thread, i.e. we may need a separate mechanism to actually apply those updates to have best protection. Since Linux does this without a Firmware / BIOS update, at least in theory it should be doable, right? Maybe via some EFI driver that does this? Link to comment Share on other sites More sharing options...
apianti Posted February 8, 2018 Author Share Posted February 8, 2018 Intel released some patches now for Skylake CPUs: https://www.engadget.com/2018/02/08/intel-spectre-cpu-patch/ and said that patch is coming for older gen CPUs. I wonder if my Haswell setup will get any UEFI updates.. No, they already released a bunch of microcode updates. The updates were recalled because they were trash and caused reboot problems, I don't expect more from the replacement skylake update, especially since it's not even hit a single machine yet. Also, the fact that the article says they had to remove one of the mitigations to get it to work, the most vulnerable one, lol. Which is why Linus is not happy with them. If you notice IB and SB never even got this mitigation in the updates anyway. Another strange thing is that the chart says stop using version C2 and continue using version C2 for skylake.... LMAO. They are completely and utterly blowing this. So that would mean that Hacks are left with open vulnerabilities where a microcode update is needed to fix or at least mitigate the problem? Which brings me to the point I made some time ago in the Clover thread, i.e. we may need a separate mechanism to actually apply those updates to have best protection. Since Linux does this without a Firmware / BIOS update, at least in theory it should be doable, right? Maybe via some EFI driver that does this? No, because OEMs should update your firmware to include the microcode updates because that is what Microsoft told them to do. Maybe for old machines, but there won't be microcode updates for those anyway, I am not even sure if they will release anything for before haswell. Link to comment Share on other sites More sharing options...
Guest Posted February 8, 2018 Share Posted February 8, 2018 https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?v=t also usable in Windows No news release here from november Link to comment Share on other sites More sharing options...
apianti Posted February 8, 2018 Author Share Posted February 8, 2018 https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?v=t also usable in Windows No news release here from november From the article that was linked a minute ago: That includes those based on technology including (but not limited to) Broadwell and Haswell which had previously seen an update that the company withdrew after reports of random reboots. Believe me Linux had them, they get released to OEMs long before they are released to the public. Link to comment Share on other sites More sharing options...
Guest Posted February 8, 2018 Share Posted February 8, 2018 Hi apianti Asus has stopped updatingbios for some motherboard as mine to new 1901 bios release because latest microcode has some big problem and produce some freeze/reboots In my case I have update to latest microcode available my old 1801 bios but I have some problem and I reverted to an oldest version supported by asus PS I believe you Link to comment Share on other sites More sharing options...
frankiee Posted February 10, 2018 Share Posted February 10, 2018 No, because OEMs should update your firmware to include the microcode updates because that is what Microsoft told them to do. Maybe for old machines, but there won't be microcode updates for those anyway, I am not even sure if they will release anything for before haswell. Well they should, but will they? And I just read that Intel plans updates for CPUs pre Haswell. So in theory there would be an update for my 4930K, but I really doubt ASUS will make BIOS updates for their X79 boards. So I still think such a mechanism (i.e. updating microcode via Clover) could be useful for a lot of users. Link to comment Share on other sites More sharing options...
maxb2000 Posted February 10, 2018 Share Posted February 10, 2018 Well they should, but will they? And I just read that Intel plans updates for CPUs pre Haswell. So in theory there would be an update for my 4930K, but I really doubt ASUS will make BIOS updates for their X79 boards. So I still think such a mechanism (i.e. updating microcode via Clover) could be useful for a lot of users. The thing is that my latest Gigabyte BIOS or better said UEFI is {censored}ed up. It's buggy as hell. So no way I will keep that BIOS if the bugs that are present in the recent versions will get into the newer BIOS with new microcode patch. When I say bugs I say: corrupted display output when no bootable device is found, sometimes the system doesn't boot, sometimes SATA devices aren't detected even with the port being enabled. I reported to Gigabyte those problems 2 years ago and just a classic response that they forwarded the meessage to the tehnical team. After 2 years no updates. Should I expect a new update now ? I don't think so. Link to comment Share on other sites More sharing options...
surfinchina Posted February 10, 2018 Share Posted February 10, 2018 Latest (f8b) x299 Gigabyte bios seems good. Has the patches, no bugginess, no slowdowns. In fact it's quite a lot faster because Gigabyte has finally fixed the XMP bug for OSx. Now I have the full 3600 instead of 2166 memory 1 Link to comment Share on other sites More sharing options...
apianti Posted February 11, 2018 Author Share Posted February 11, 2018 Hi apianti Asus has stopped updatingbios for some motherboard as mine to new 1901 bios release because latest microcode has some big problem and produce some freeze/reboots In my case I have update to latest microcode available my old 1801 bios but I have some problem and I reverted to an oldest version supported by asus PS I believe you Well they should, but will they? And I just read that Intel plans updates for CPUs pre Haswell. So in theory there would be an update for my 4930K, but I really doubt ASUS will make BIOS updates for their X79 boards. So I still think such a mechanism (i.e. updating microcode via Clover) could be useful for a lot of users. As I said, most likely not. Also, the most salient part of this is that the operating systems have already done what is needed to protect you, separate the memory maps of the kernel and user spaces. The microcode update is all MITIGATIONs, there are no other non-silicon FIXES besides the memory map separating. It is IMPOSSIBLE to fix this problem without redesigning the CPU pipeline itself, because the problem is the CPU pipeline (which is why it affects almost every x86 compatible CPU). When it needs to try to guess (predict) what's going to happen for a branching action based on previous actions, it doesn't check if the instructions following will be executed in the same protection domain, in multiple different ways, lol. Allowing for injection during the context switch as well as kernel memory leaking such as private crypto keys. Latest (f8b) x299 Gigabyte bios seems good. Has the patches, no bugginess, no slowdowns. In fact it's quite a lot faster because Gigabyte has finally fixed the XMP bug for OSx. Now I have the full 3600 instead of 2166 memory If you didn't have working XMP in macOS then you didn't have it in any OS. I wrote the code for XMP detection and RAM table injection because I needed XMP. Or you disabled the detection/injection before.... EDIT: Probably meant detection but I guess injection works fine too so I'll leave both... 1 Link to comment Share on other sites More sharing options...
surfinchina Posted February 12, 2018 Share Posted February 12, 2018 If you didn't have working XMP in macOS then you didn't have it in any OS. I wrote the code for XMP detection and RAM table injection because I needed XMP. Or you disabled the detection/injection before.... EDIT: Probably meant detection but I guess injection works fine too so I'll leave both... I would have thought so too! But, I remember some time ago and can no longer find it, that the X299 Gigabyte motherboards couldn't go faster that 2166 mem on OS x, but could on the windows. That seems to be solved now, whether it's the new bios or the 10.13.4 I don't know, I did them at the same time. It just happened that my memory without XMP was 2166. In fact, I am old and forgetful, but I think I remember that was also a bug with the windows right at the beginning of the release of that motherboard. Link to comment Share on other sites More sharing options...
apianti Posted February 12, 2018 Author Share Posted February 12, 2018 I would have thought so too! But, I remember some time ago and can no longer find it, that the X299 Gigabyte motherboards couldn't go faster that 2166 mem on OS x, but could on the windows. That seems to be solved now, whether it's the new bios or the 10.13.4 I don't know, I did them at the same time. It just happened that my memory without XMP was 2166. In fact, I am old and forgetful, but I think I remember that was also a bug with the windows right at the beginning of the release of that motherboard. Far more likely that the firmware was not properly enabling XMP, and you never had it. Windows was probably reading your SMBIOS and when showing you the speed, when it was injected into macOS, clover checked and saw that it wasn't enabled so injected normal speed of your RAM. I just had this issue with a firmware update, I updated to the newest version and XMP was gone, it said it was enabled but even in the firmware menu it said 1333, instead of 1600. In windows it said that I had XMP enabled but all the stuff still said 1333, reflashed previous, and it was back to normal.... 1 Link to comment Share on other sites More sharing options...
frankiee Posted April 8, 2018 Share Posted April 8, 2018 Does anyone know if there is a tool for macOS for checking actual vulnerability? I have installed a patched BIOS (with latest microcode) for my R4BE, and on windows it says that I am in fact now fully protected. Now I am curious if that BIOS update has any effect on the mac side. Link to comment Share on other sites More sharing options...
Allan Posted April 8, 2018 Share Posted April 8, 2018 macOS High Sierra already had the patch. 1 Link to comment Share on other sites More sharing options...
frankiee Posted April 8, 2018 Share Posted April 8, 2018 Yeah, but how can I verify it is effectively working? At least for the windows side, the BIOS update was mandatory to be fully protected. So if they did a firmware update for "real macs", we still won't have that on a hack. Link to comment Share on other sites More sharing options...
frankiee Posted April 8, 2018 Share Posted April 8, 2018 LOL yeah, go ahead and try it Seriously, is there another way to find out? Link to comment Share on other sites More sharing options...
apianti Posted April 8, 2018 Author Share Posted April 8, 2018 (edited) If you updated your firmware because it included a microcode update, then that microcode update is applied to everything. The microcode update can only be updated to a higher version after that. So in order for the update to not be used/protecting you, you would need to downgrade your firmware again. However, linux and windows frequently have microcode updates in the OS, I do not know if macOS does this, I'm pretty sure that they are all firmware updates. This doesn't really matter though since your microcode update is persistent because it is applied at boot before anything else could possibly modify it, save an attack on a vulnerability but that's another thing all together and very unlikely you will ever have to worry, let alone think about that. EDIT: Double posted on accident, removed duplicate. Edited April 8, 2018 by apianti 3 Link to comment Share on other sites More sharing options...
frankiee Posted April 8, 2018 Share Posted April 8, 2018 OK, so I should be protected also on macOS now? As I have dual BIOS (currently one patched and one unpatched) it would relatively easy for me to switch back, and if only for testing purposes. I was just curious if the patch is actually also effective on macOS, but if I understand you correctly, this should be the case. Link to comment Share on other sites More sharing options...
apianti Posted April 8, 2018 Author Share Posted April 8, 2018 5 minutes ago, frankiee said: OK, so I should be protected also on macOS now? As I have dual BIOS (currently one patched and one unpatched) it would relatively easy for me to switch back, and if only for testing purposes. I was just curious if the patch is actually also effective on macOS, but if I understand you correctly, this should be the case. You do understand and are protected. 3 Link to comment Share on other sites More sharing options...
ammoune78 Posted April 8, 2018 Share Posted April 8, 2018 By the way, There's UBU Bios updater, that update CPU Microcode and OROM's for AMI bioses, this is useful for anyone that don't have bios updated since the CPU's vulnerability from Manufacturers website! And i guess that we still need "Microcode Bios Updated + OS Updated" to be relatively protected 2 Link to comment Share on other sites More sharing options...
Riley Freeman Posted April 9, 2018 Share Posted April 9, 2018 Yeah, I updated all three machines in my sig with UBU a little while back. Doubt any of them will see official BIOS updates. Link to comment Share on other sites More sharing options...
ammoune78 Posted April 9, 2018 Share Posted April 9, 2018 Hey Riley how are you , I don't think that it will be a BIOS update by the manufacturers, unless a release for OEM machines Link to comment Share on other sites More sharing options...
Thomas Stats Posted December 1, 2018 Share Posted December 1, 2018 On 1/3/2018 at 5:38 PM, apianti said: Yes. It is a vulnerability in Intel CPUs themselves. I've found other sources that have said almost every Intel CPU in the past 12 years has this vulnerability - across families and models. Although some newer generations have models that have a feature, PCID (Process-Context IDentifiers), that unintentionally mitigates this is partially so it won't take as much of a performance hit but still affected. A new serious side-channel vulnerability has been discovered in Intel CPUs by a team of security researchers. The flaw could enable malicious actors to access processes that are running in the same CPU core with simultaneous multithreading technology and steal sensitive information, such as passwords or cryptographic keys. PortSmash vulnerability tracked as CVE-2018-5407 Link to comment Share on other sites More sharing options...
Recommended Posts