Obviously they do have a bios fix but it's up the the OEM's to take the time to put that into a new bios update and that is not profitable for them on older boards. It'll probably come down to those that are tech savy to provide bios patches for older boards when the bios microcode becomes available for all
Maybe someone will/can do that here but there's one hell of a lot of older boards out there today. All the current boards that have a modified SLIC bios will need to have an update, and a new SLIC (or the old SLIC re-added to the updated bios)
When they say "as prioritized by our customers" it makes me think they'll only patch a few of them if there's a demand for it. Personally I think Intel might release a few updates for older Xeon processors, but beyond that they're probably hoping that Microsoft adds Retpoline support. They've already said that the Retpoline technique may perform better than their own solution. Spoiler: Retpoline If you do notice a difference in performance it'll be with storage I/O benchmarks, but it should still give a similar or better result than an updated BIOS. Code: spectre_v2= [X86] Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability. on - unconditionally enable off - unconditionally disable auto - kernel detects whether your CPU model is vulnerable Selecting 'on' will, and 'auto' may, choose a mitigation method at run time according to the CPU, the available microcode, the setting of the CONFIG_RETPOLINE configuration option, and the compiler with which the kernel was built. Specific mitigations can also be selected manually: retpoline - replace indirect branches retpoline,generic - google's original retpoline retpoline,amd - AMD-specific minimal thunk ibrs - Intel/AMD microcode feature Not specifying this option is equivalent to spectre_v2=auto.
We are just SOL if we have older boards, Looks like they could care less but I'm thinking that the industry as a whole might pressure board oem's to patch older boards to prevent any spreading of the flaw Edit: Then again maybe not?
...not necessarily...not more than others....it is a general and major vulnerability based on a design flaw. We should not forget that the cause resides in the CPU (hardware) itself. AND branch prediction which is affected is responsible to have today's performance. I assume that spectre never gets fully patched/eliminated except by redesign of CPU. Even if the 'tools' report some day no vulnerability to spectre 1/2 and meltdown you cannot say that you are safe now. It concerns a basic CPU feature 'prediction' and speculation and also caching. Intel could disable the entire prediction, but then you would just have a CPU performance which is comparable to the millennium 2000. Anything will lead to a compromise where performance loss is still acceptable but spectre attacks still possible.... The fight against spectre will finally be made by recognition of malicious code. It will be a cat and mouse game until the real cause vanishes...(the affected CPUs)... Btw: 32-bit windows versions are still vulnerable to both. M$ did nothing so far.....
It's going to vary from program to program. The amount of performance loss will be inversely proportional to what steps the programmer(s) took to optimize their software. Programs like CAD and DAWs might take a bad hit. CAD because of the graphics calculations (Although these can and will be minimized by use of the on board Floating Point coprocessor.) DAWs might not be so lucky, in that they typically use their own Floating point format (32 bit) which doesn't (IIRC) work with the FPU. Not only is every OS affected, every compiler is affected too. That means that every program that is time intensive will need to be recompiled, and re-optimized for performance. There's going to be a -LOT- of software consulting work coming up over the next year or so. Just like Y2K.
Like I said in another post, it's not a question of what Intel is able to do in order to resolve the problem. The real question is what are they willing to do? And at what cost? I'm sure their accountants and their lawyers will have the final say in this.
@john: The standard corporate line is "Duck and Weave." The CPU makers are going to blame it on the BIOS and the OS. The BIOS makers are only going to be able to do so much. So the rest of the mess falls on the OS makers and the compiler writers.