Intel bug incoming.

Maelstorm said:
As a student of computer science myself, what I do not understand is why use the shotgun approach rather than use Intel's procedure to determine which file to load? I mean, the procedure is published by the CPU vendor so why not use it? It would cause a lot less headaches if people coded to spec as documented instead of trying to do something quick and dirty, which might bite you in the long run.
Click to expand...
Basically the procedure is simple. Take the the cpu family, model, stepping and microcode version. Then look what of those files is the next successor (same family/model, higher microcode version).
With the information Intel provided and the easy-to-understand file naming convention, one can even manually easily identify which file is the correct one.
The approach used by the cpucontrol program is completely different than this.

I am playing around with cpucontrol.c and intel.c atm, implementing an option -f to manually specify the microcode file to load, and correcting the code in intel.c regarding processor and microcode identification so it can correctly determine whether the file given as parameter actually is a compatible one.
When the results seem OK, I'll uncomment the actual uploading code and see what happens.

I don't think that an option to specify a microcode file manually is a shotgun approach, because there are (albeit rare) use cases even when the algorithm to determine the correct file has been implemented. (think of microcode testing, etc).

When this works, the next step would be to correct the code in cpucontrol.c to find just that file and feed it to intel_update().
When this is done, I'll submit that in a PR as suggestion to the devs. The reason is that I feel annoyed by the fact that there is still no information when we FreeBSD guys will get our microcode update, even 10 days after the embargo end. I want this to happen (at least for me) before the first meltdown malwares start circulating. I don't want to be hacked just by some malicious javascripts I drive by (Microsoft Security has reportedly already made working proof-of-concept exploit scripts for this)

Your CPU detecting code is a really sweet hack :) Today this is much easier... The basic information about cpuid regarding this is very well explained in figure 3-6 on page 3-204 in Intels instruction reference.
 
Snurg said:
I don't think that an option to specify a microcode file manually is a shotgun approach, because there are (albeit rare) use cases even when the algorithm to determine the correct file has been implemented. (think of microcode testing, etc).
Click to expand...

I didn't say that specifying a microcode file manually was the shotgun approach. What I was referring to was the implementation of cpucontrol.c and intel.c that you described which goes through and tries each file until something loads.

Snurg said:
The reason is that I feel annoyed by the fact that there is still no information when we FreeBSD guys will get our microcode update, even 10 days after the embargo end. I want this to happen (at least for me) before the first meltdown malwares start circulating.
Click to expand...

I believe that Intel has already released the microcode. Microcode is not OS or BIOS specific. It is CPU specific. OS doesn't matter as long as you have a tool to load the file into CPU.

Snurg said:
Your CPU detecting code is a really sweet hack :) Today this is much easier... The basic information about cpuid regarding this is very well explained in figure 3-6 on page 3-204 in Intels instruction reference.
Click to expand...

I originally wrote that code while I was still in high school in the late 1980's to early 1990's when there was several different types of x86 CPUs out there with way different specs. I posted it to a BBS and it spread from there. The code was originally designed to work with Borland's Turbo Pascal. But it can be used with any language. It was part of a game engine that I was writing. I was going to sell it, but then Windows 95 came on to the scene and it was rendered obsolete.

Believe it or not, there are still some 80486's out there still working. Solid equipment if a bit dated.
 
I updated sysutils/devcpu-data today and ran it again on the same machine with different results:

Code: 
root@relentless:/ # service microcode_update start
Updating CPU Microcode...
Please update your system in order to update CPU microcode.
Done.
root@relentless:/ # grep micro /var/log/messages
root@relentless:/ #
Now what? It is up to date.

Code: 
root@relentless:/ # freebsd-version -k
11.1-RELEASE-p4
root@relentless:/ # freebsd-version -u
11.1-RELEASE-p6
 
Yeah here too, but my system is 11.1-STABLE from august 2017 so that's possible. /usr/sbin/cpucontrol is a base program.
 
Trihexagonal said:
I updated sysutils/devcpu-data today and ran it again on the same machine with different results:

Code: 
root@relentless:/ # service microcode_update start
Updating CPU Microcode...
Please update your system in order to update CPU microcode.
Done.
root@relentless:/ # grep micro /var/log/messages
root@relentless:/ #
Now what? It is up to date.

Code: 
root@relentless:/ # freebsd-version -k
11.1-RELEASE-p4
root@relentless:/ # freebsd-version -u
11.1-RELEASE-p6
Click to expand...

It’s being prepared for whenever the new release (which supports -e) is cut.

https://svnweb.freebsd.org/ports/he..._update.in?r1=459084&r2=459083&pathrev=459084
 
So, since I am about to buy a new system, AMD based, if I wait long enough, say April 2018, would the (1st generation) Ryzen CPU, and motherboard, I buy already have these microcode updates done? I say 1st generation Ryzen, because I understand 2nd generation will be released in April, which I don't think I am buying.
 
shepper said:
CPU microcode is loaded during boot from storage media (hard drive, ssd, etc) and goes away when the system is powered off.
Click to expand...

OKay, but my question still remains: Will new releases of the current generation of CPU and motherboards have the fix built into them, or will this piece of microcode go on for the foreseeable future? In other words will newly made batched of CPUs and motherboards incorporate the permanent fix, or will it have to be new generations of CPU (think Ryzen 2nd or 3rd gen, or Intel Core i5-9xxx for example). After all this was reported as a CPU hardware problem, that itself can't be fixed, so the work around was kernel and/or micocode updates. So all I am asking is can we expect future versions of these CPU to have the necessary hardware changes baked inside, or will we still need this work around?
 
Trihexagonal said:
I updated sysutils/devcpu-data today and ran it again on the same machine with different results:

Code: 
root@relentless:/ # service microcode_update start
Updating CPU Microcode...
Please update your system in order to update CPU microcode.
Done.
root@relentless:/ # grep micro /var/log/messages
root@relentless:/ #
Now what? It is up to date.

Code: 
root@relentless:/ # freebsd-version -k
11.1-RELEASE-p4
root@relentless:/ # freebsd-version -u
11.1-RELEASE-p6
Click to expand...



Code: 
root@realfascism:~ # freebsd-version -k
11.1-RELEASE-p4
root@realfascism:~ # freebsd-version -u
11.1-RELEASE-p6

same here! why am I not on 6? is 6 stuff for non amd64?
 
azathoth said:
same here! why am I not on 6? is 6 stuff for non amd64?
Click to expand...

No kernel changes from -p4 to p6:
# svn diff --summarize -r r325875:HEAD
M UPDATING
M crypto/openssl/crypto/bn/asm/rsaz-avx2.pl
M crypto/openssl/crypto/bn/asm/x86_64-mont5.pl
M crypto/openssl/crypto/x509v3/v3_addr.c
M crypto/openssl/ssl/ssl.h
M secure/lib/libcrypto/amd64/rsaz-avx2.S
M secure/lib/libcrypto/amd64/x86_64-mont5.S
M sys/conf/newvers.sh
 
azathoth said:
Code: 
root@realfascism:~ # freebsd-version -k
11.1-RELEASE-p4
root@realfascism:~ # freebsd-version -u
11.1-RELEASE-p6

same here! why am I not on 6? is 6 stuff for non amd64?
Click to expand...

To have same version you can build the kernel from sources.

ex.
Code: 
 freebsd-version -ku                                                                                                                    
11.1-RELEASE-p6
11.1-RELEASE-p6
 
PacketMan said:
OKay, but my question still remains: Will new releases of the current generation of CPU and motherboards have the fix built into them, or will this piece of microcode go on for the foreseeable future?
Click to expand...

The fix will not be built into the motherboard. It is more like a firmware update and in this instance, Intel/AMD have existing cpu microcode which is in the process of being updated to address the security issue. The advantage of microcode/firmware, is that the issue can be dealt with by a download rather than buying new hardware.

Firmware/microcode is usually propriatory/closed source. The FreeBSD developers have written a utility to load the microcode and have to hope that Intel/AMD provide secure, compatible code. The FreeBSD developers may not be able to audit the code without a Non-Disclosure-Agreement.
 
shepper said:
The fix will not be built into the motherboard.
Click to expand...

Okay thanks. However I am not asking really about the motherboard. All I am trying to determine is if/when future releases of CPUs from Intel and AMD (AMD really for me), will not have this hardware issue inside the CPU. When will the issue be fixed inside the CPU, and thus a workaround outside the CPU is not required.
 
You must log in or register to reply here.
Back
Top