Yes, with UBU v1.69.16 and Intel Ivy Bridge-DT (CPUID=306A9) Core-I7-3770K modded BIOS with µC=x1F and W10 x64 RS3 Build 16299.251 the Meltdown and Spectre Vulnerability issue is fixed.
UBU 1.69.16/1.70.a15 outputs files that are slightly different from the files created by 1.69.15/1.70.a14. The difference is only in 3 bytes. Is this normal behavior?
Here’s an example with two modified and one original file: http://www49.zippyshare.com/v/WULKvC02/file.html
@Fernando
First of all, thanks, I did it.
Used UBU_v1_69_16 with MMTool 5.02_patched.
Used microcode update function and “m” (manual) mode to prevent Ivy Bridge microcode update (I read here that it could result in random BSOD, now I can’t find the source).
Flashed successfully.
Now the question is, re-opening the modified bios with UBU shows a microcode for Sandy Bridge CPUs only, no Ivy Bridge at all…
I did something wrong, my bad…
Here is the picture:
@thecrowler
The same thing happened on mine, but it isn’t a problem - unless you have an Ivy Bridge processor, that mcode is unused. Are you really going to upgrade to an Ivy Bridge processor or would you just get a much newer generation platform? Even if you did upgrade to Ivy Bridge, you could re-flash with the Ivy Bridge mcode just before changing the CPU.
Confirmed.
@ygbsm
You’re right, of course, I’m just trying to understand if I did it wrong. Thank you very much for your answer.
The correct way to do the microcode update was to let UBU do it automatically using option “1” (both for Sandy and Ivy Bridge)?
“Even if you did upgrade to Ivy Bridge, you could re-flash with the Ivy Bridge mcode just before changing the CPU” - so you mean, to update both microcodes BEFORE using an Ivy Bridge CPU?
I’m asking, 'cause flashing a bios (with a Sandy Bridge inside) that contain an incorrect/not supported microcodes, sounds very risky, also when you plan an instant CPU change.
There’s no way for an Ivy Bridge microcode to cause any stability issues if you’re not even using Ivy Bridge CPU.
And the final microcode for Ivy Bridge was released just a few days ago, so if you’ve heard about BSOD more than a week ago, then it probably was something completely unrelated.
@Bugger Vance
Post #3743, author @ygbsm
Sandy and Ivy Bridge CPU microcodes on a Sandy Bridge Z68, they both use an share offset 0x347390.
and Post #3755, author @mictlan
I don’t think that’s possible. Two microcodes can’t be located at exact same place in the BIOS ROM, because then one of them of the would overwrite another.
@Bugger Vance
Of course, it could not be: but that’s what UBU shows, you can clearly read it on the attached images on #3743.
That’s also what I saw when I did it.
See also post #3755, author: @mictlan
All of the offsets on those images are different, as they should be.
Sorry, I read it too fast.
Anyway, microcode sizes doesn’t match, and the “boot looping” described was the reason why I did a manual update.
Hope I did it right.
Good evening, sorry for the dumb question, I have an Asrock Z170 Extreme 4 mb, i’m trying once again to fully update my bios (irst, orom, video, lan and microcode) using UBU v1.69_16 everything seems ok until I update the microcodes (i’m actually vulnerable to spectre), this is the output:
Current New
01 mCode Address - FFE10280 != FFE10268
Fixed - FFE10268
mCode Size - 18000
02 mCode Address - FFE28280 != FFE28268
Fixed - FFE28268
mCode Size - 18400
Clearly the microcode address are different, should I try to flash this bios anyway or what can I do?
Thank you in advance.
Make sure you’re using the latest version 7 of Inspectre which tests properly for CPUID
Previous versions of Inspectre didn’t have that feature so could have given conflicting info…
Notice the offsets are clearly different for the range of CPUIDs in column 1 and 2 in my own case
and there is NO PERFORMANCE HIT!
Cheers
MB: Asus Z87-Deluxe
The fact that some program tells you that there is no performance loss doesn’t mean anything, really. The only way to determine whether or not there is a performance loss is to run real benchmarks before and after the updates. All of the Spectre/Meltdown-related updates aren’t going to make your PC faster, that’s for sure.
Oh, and there’s no need to use any third-party programs (which may or may not be accurate) for testing - there is an official PowerShell module for this:
https://support.microsoft.com/en-us/help…nerabilities-in
@thecrowler
If you did the manual update, then UBU placed the single mcode .bin file you selected into the first offset slot. This is what I had to do also, as my BIOS insisted on reading the mcode in slot #1 after this mcode update. Previously, my BIOS read the correct slot for my CPU. So the auto update (option “1” in UBU) placed the Ivy Bridge mcode in slot #1 which causes endless boot loops for my Sandy Bridge system. Even though the other mcodes are now gone, there’s no real loss because we can only use one mcode at a time anyway. It looks like your system is checking out on InSpectre, so I’d say you did the update “correctly”.
@Nemo1985
The way I’m reading that output, is that UBU is correcting the FIT address offsets, which is the fix introduced in 1.69.16. Note that my 6-series motherboard doesn’t implement FIT , so I can’t speak from direct experience. From your motherboard spec, you have a dual BIOS - so in the worst case scenario, you should be able to recover from that. Just familiarize yourself with the procedure before you flash your BIOS; for example, on my Gigabyte BIOS it was a combination of pressing the power and reset buttons for 10 sec., after which the backup BIOS kicked in. I used it to recover when using the standard option “1” in UBU to update my mcodes resulted in endless boot loops after flashing. I brought back the backup BIOS, updated the newer BIOS image mcode in “m” (User Select) UBU mode, then successfully flashed that to my BIOS.
@hancor
I’m reading your mcode list as two duplicates - usually multiple entries will either differ in the CPUID (so a single board can support multiple CPU types) or their revision #. It’s odd, but in your case it appears you have the correct mcode (0x24 per Intel recommendations) for you processor, so that’s all that matters.
@Bugger Vance
There is the powershell script, but when I tried it, it required changing permissions that I’d rather not touch. InSpectre is good and doesn’t require permission changes, plus it allows the OS fixes to be enabled/disabled as the need arises, such as when the meltdown fix makes older computers so slow as to be barely usable. The developer, Steve Gibson (GRC.com), knows his stuff.
It’s definitely a problem if some motherboards with support for multiple CPU types (Sandy/Ivy) will work with the modded BIOS only after you remove the microcode for one of the CPU types entirely. Especially when there’s no clear reason for this to happen, according to the developer of UBU:
This has to be some kind of bug.
@ygbsm
Thank you, yes my mb has dual bios I never used it but I know that there is a switch on my mb, Ill have to open the case.
This is the situation before and after the update, let’s see if someone else can say if I can safely flash or not…
@Bugger Vance
Finding out there is no FIT on my board was a surprise to me - I’m not sure what mechanism my BIOS used to previously select the correct mcode offset out of a long list. I agree that UBU wiping out all mcode save one or two is a bug, but I’m not sure fixing it will be worthwhile. We have to consider that these older platforms are at the end of the support cycle, and very few of them will be upgraded to a different processor than their current one. The vast majority of people will simple buy a completely new platform several generations newer when upgrading. We have also discovered a workaround with the manual update, and it works well enough since we can only use one microcode at a time anyway. It’s also doubtful that this generation of processors will receive any further mcode updates. All that considered, we have to be considerate of SoniX’s time and whether it is best spent fixing what can be considered an edge case. Perhaps it’s a super simple fix - that’s for SoniX to say. I’ve offered up multiple versions of my BIOS image to him if he should decide to pursue it. The remedy may realistically end up being to update the guide to recommend manual updating for these older boards.
@Nemo1985
I did a little reading, it appears that flashing the backup BIOS on your board requires setting jumpers as opposed to pressing buttons. I agree that it’s reasonable for you to wait to see what information others have before taking action, especially since it looks like your new mcode have new sizes and new offsets. Even the first slot has a new offset. That would be enough to give me pause too.