51–60 of 112 posts
Despite the name, this is not Linux-specific microcode. If you're running SmartOS or another illumos derivative, run ucodeadm(1) on the microcode.dat file (which will need to be renamed to have an "intel" prefix per the man page -- e.g., "intel-code.txt"). You can then run "ucodeadm -v" to validate that the new microcode has been loaded. (Note that this does not persist across a reboot, but we at Joyent are currently…
Earlier quoted context omitted.
> Literally tells us nothing about what's in it. Not even a changelog. Not even a sentence hinting as to what might be in it. Incredible. They do have ./releasenote: Intel Processor Microcode Package for Linux 20180108 Release -- Updates upon 20171117 release -- IVT C0 (06-3e-04:ed) 428->42a SKL-U/Y D0 (06-4e-03:c0) ba->c2 BDW-U/Y E/F (06-3d-04:c0) 25->28 HSW-ULT Cx/Dx (06-45-01:72) 20->21 Crystalwell Cx (06-46-01:32…
The characters after the shorthand are probably chip revision. {HSW,BDW,SKL,KBL,CFL} are probably Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake. {HSX,BDX,SKX} appear to be the codenames for some variants of Haswell/Broadwell/Skylake - I find mixes of references to those being the Xeons, associated chipsets, and otherwise. GLK appears to be Gemini Lake, a codename for some of Intel's really low power SoCs.
Earlier quoted context omitted.
apt-get install intel-microcode https://wiki.debian.org/Microcode then follow the "releasenote".
I was just explained the other day on Hacker News how CPU microcode gets delivered with the Kernel. That it gets installed automatically on every boot. Why is it a separate package (which it turns out I don't have).
Intel places restrictions against reverse engineering the microcode, as well as it not being in the prefered original source. Both of these violate the Debian Free Software Guidelines, and thus it can only be in non-free at best.
Earlier quoted context omitted.
It does say "Debian Linux*", which I take to include Debian 9.
says debian 8.* and 7.* which i take to mean 8.1 and 7.1, expressly excluding 9
Intel, AMD and Via microcode is being archived by CPUID, by the user community: https://www.win-raid.com/t3355f47-Intel-AMD-amp-VIA-CPU-Micr... "Collecting all available Production CPU microcodes is important for upgrading/downgrading purposes, for creating universal tools that can help people understand what microcode they use, for research on how the general technology works, for developers with no vendor represent…
I always assumed they were not just signed but encrypted, and padded to avoid meta analysis. Is that not the case?
In this case, someone who dreams in hardware, breathes ASM and talks in bytes, needs to clearly inform the community here concerning these questions:
- SHOULD THIS MICROCODE UPDATE BE PERFORMED SEPARATELY FROM RUNNING: apt-get update && apt-get upgrade ?
- WHAT IS THE IDEAL/BEST WAY TO PERFORM THIS MICROCODE UPDATE?
Earlier quoted context omitted.
apt-get install intel-microcode https://wiki.debian.org/Microcode then follow the "releasenote".
I was just explained the other day on Hacker News how CPU microcode gets delivered with the Kernel. That it gets installed automatically on every boot. Why is it a separate package (which it turns out I don't have).
Also another big issue issue is the Intel microcode is proprietary, so separating it from the kernel means that user could selectively pick and choose if wants to have a totally free system, which would mean not loading microcode updates with a libre kernel. This is done for instance with Parabola and Trisquel distros, which is needed to obtain FSF's totally free certification.
Earlier quoted context omitted.
And no reverse engineering possible? I'm a bit surprised there is no enthusiast blog that tries to document intel microcode changes, but maybe I just haven't found it yet.
It's being reverse engineered as we speak. Great CCC talk from a couple of weeks ago: https://www.youtube.com/watch?v=lY5kucyhKFc
Despite the name, this is not Linux-specific microcode. If you're running SmartOS or another illumos derivative, run ucodeadm(1) on the microcode.dat file (which will need to be renamed to have an "intel" prefix per the man page -- e.g., "intel-code.txt"). You can then run "ucodeadm -v" to validate that the new microcode has been loaded. (Note that this does not persist across a reboot, but we at Joyent are currently…
And slow down my computer? No thanks.
This is totally different from the kernel PTI fixes, which attempt to deal with Meltdown by changing the way the operating systems for Linux/Mac/Windows/DragonFly (and hopefully soon *BSD) interacts with the hardware and page tables.
Also you're making a statement without the above comment even stating if this update is designed to address Spectre or Meltdown.
HN really needs a sticky feature for comments concerning security patches and other updates that can bork your machine. In this case, someone who dreams in hardware, breathes ASM and talks in bytes, needs to clearly inform the community here concerning these questions: - SHOULD THIS MICROCODE UPDATE BE PERFORMED SEPARATELY FROM RUNNING: apt-get update && apt-get upgrade ? - WHAT IS THE IDEAL/BEST WAY TO PERFORM THIS…
People on the unstable branches will get to test it first and give appropriate feedback before it gets marked stable, and there will also most likely be a delay before a kernel is released that re-enabled PTI (once again, if this is a PTI/Meltdown fix).