The latest Intel microcode fail to install on Debian Stretch

Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I'm trying to patch for Spectre variant 2 on my computer running Debian Stretch. I have installed the intel-microcode package from strech-backports
https://packages.debian.org/stretch-backports/intel-microcode
which includes the 2018-03-12 microcode updates from Intel. After a reboot I run sudo dmesg | grep 'microcode' and get
[ 1.180101] microcode: sig=0x30678, pf=0x8, revision=0x831
[ 1.180418] microcode: Microcode Update Driver: v2.01
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
which, as far as I can tell, isn't the lastest version for my processor. My processor is an Intel Celeron N2840 and is in the Bay Trail family. According to
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf
all Bay Trail should have gotten a microcode update but no revision equals the revision I have. Furthermore, the spectre-meltdown-checker.sh script says
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full
generic retpoline - vulnerable module loaded)
* Mitigation 1
* Kernel is compiled with IBRS support: NO
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel
reports full retpoline compilation)
> STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate
the vulnerability)
How can I make sure the microcode update is installed properly and is used?
Edit some hours later
I performed the procedure I outlined above on a computer with an Intel Core i5-5200U processor (Broadwell), also on Debian Stretch. On that computer, the scripts says "not vulnerable" and that I have microcode that mitigates spectre v2. dmesg | grep 'microcode' also shows that I have the revision mentioned in Intel's document linked above.
I also performed the procedure on a computer with an old Intel Core 2 Duo Penryn processor, which Intel won't give microcode for that mitigates spectre v2. This is the result from the script on that computer
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline)
* Mitigation 1
* Kernel is compiled with IBRS support: NO
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline is mitigating the vulnerability)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation, but your CPU microcode doesn't support it
which I interpret as that the reptoline mitigates spectre v2 (only attacks on the kernel, right?) but that a microcode update is recommended for IBPB.
Shouldn't my first computer (the one with an Intel Celeron N2840 processor) have at least the same reptoline mitigation as my last computer? Shouldn't it also have the microcode mitigation as the middle computer?
debian security
add a comment |Â
up vote
3
down vote
favorite
I'm trying to patch for Spectre variant 2 on my computer running Debian Stretch. I have installed the intel-microcode package from strech-backports
https://packages.debian.org/stretch-backports/intel-microcode
which includes the 2018-03-12 microcode updates from Intel. After a reboot I run sudo dmesg | grep 'microcode' and get
[ 1.180101] microcode: sig=0x30678, pf=0x8, revision=0x831
[ 1.180418] microcode: Microcode Update Driver: v2.01
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
which, as far as I can tell, isn't the lastest version for my processor. My processor is an Intel Celeron N2840 and is in the Bay Trail family. According to
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf
all Bay Trail should have gotten a microcode update but no revision equals the revision I have. Furthermore, the spectre-meltdown-checker.sh script says
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full
generic retpoline - vulnerable module loaded)
* Mitigation 1
* Kernel is compiled with IBRS support: NO
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel
reports full retpoline compilation)
> STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate
the vulnerability)
How can I make sure the microcode update is installed properly and is used?
Edit some hours later
I performed the procedure I outlined above on a computer with an Intel Core i5-5200U processor (Broadwell), also on Debian Stretch. On that computer, the scripts says "not vulnerable" and that I have microcode that mitigates spectre v2. dmesg | grep 'microcode' also shows that I have the revision mentioned in Intel's document linked above.
I also performed the procedure on a computer with an old Intel Core 2 Duo Penryn processor, which Intel won't give microcode for that mitigates spectre v2. This is the result from the script on that computer
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline)
* Mitigation 1
* Kernel is compiled with IBRS support: NO
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline is mitigating the vulnerability)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation, but your CPU microcode doesn't support it
which I interpret as that the reptoline mitigates spectre v2 (only attacks on the kernel, right?) but that a microcode update is recommended for IBPB.
Shouldn't my first computer (the one with an Intel Celeron N2840 processor) have at least the same reptoline mitigation as my last computer? Shouldn't it also have the microcode mitigation as the middle computer?
debian security
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I'm trying to patch for Spectre variant 2 on my computer running Debian Stretch. I have installed the intel-microcode package from strech-backports
https://packages.debian.org/stretch-backports/intel-microcode
which includes the 2018-03-12 microcode updates from Intel. After a reboot I run sudo dmesg | grep 'microcode' and get
[ 1.180101] microcode: sig=0x30678, pf=0x8, revision=0x831
[ 1.180418] microcode: Microcode Update Driver: v2.01
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
which, as far as I can tell, isn't the lastest version for my processor. My processor is an Intel Celeron N2840 and is in the Bay Trail family. According to
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf
all Bay Trail should have gotten a microcode update but no revision equals the revision I have. Furthermore, the spectre-meltdown-checker.sh script says
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full
generic retpoline - vulnerable module loaded)
* Mitigation 1
* Kernel is compiled with IBRS support: NO
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel
reports full retpoline compilation)
> STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate
the vulnerability)
How can I make sure the microcode update is installed properly and is used?
Edit some hours later
I performed the procedure I outlined above on a computer with an Intel Core i5-5200U processor (Broadwell), also on Debian Stretch. On that computer, the scripts says "not vulnerable" and that I have microcode that mitigates spectre v2. dmesg | grep 'microcode' also shows that I have the revision mentioned in Intel's document linked above.
I also performed the procedure on a computer with an old Intel Core 2 Duo Penryn processor, which Intel won't give microcode for that mitigates spectre v2. This is the result from the script on that computer
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline)
* Mitigation 1
* Kernel is compiled with IBRS support: NO
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline is mitigating the vulnerability)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation, but your CPU microcode doesn't support it
which I interpret as that the reptoline mitigates spectre v2 (only attacks on the kernel, right?) but that a microcode update is recommended for IBPB.
Shouldn't my first computer (the one with an Intel Celeron N2840 processor) have at least the same reptoline mitigation as my last computer? Shouldn't it also have the microcode mitigation as the middle computer?
debian security
I'm trying to patch for Spectre variant 2 on my computer running Debian Stretch. I have installed the intel-microcode package from strech-backports
https://packages.debian.org/stretch-backports/intel-microcode
which includes the 2018-03-12 microcode updates from Intel. After a reboot I run sudo dmesg | grep 'microcode' and get
[ 1.180101] microcode: sig=0x30678, pf=0x8, revision=0x831
[ 1.180418] microcode: Microcode Update Driver: v2.01
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
which, as far as I can tell, isn't the lastest version for my processor. My processor is an Intel Celeron N2840 and is in the Bay Trail family. According to
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf
all Bay Trail should have gotten a microcode update but no revision equals the revision I have. Furthermore, the spectre-meltdown-checker.sh script says
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full
generic retpoline - vulnerable module loaded)
* Mitigation 1
* Kernel is compiled with IBRS support: NO
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel
reports full retpoline compilation)
> STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate
the vulnerability)
How can I make sure the microcode update is installed properly and is used?
Edit some hours later
I performed the procedure I outlined above on a computer with an Intel Core i5-5200U processor (Broadwell), also on Debian Stretch. On that computer, the scripts says "not vulnerable" and that I have microcode that mitigates spectre v2. dmesg | grep 'microcode' also shows that I have the revision mentioned in Intel's document linked above.
I also performed the procedure on a computer with an old Intel Core 2 Duo Penryn processor, which Intel won't give microcode for that mitigates spectre v2. This is the result from the script on that computer
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline)
* Mitigation 1
* Kernel is compiled with IBRS support: NO
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline is mitigating the vulnerability)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation, but your CPU microcode doesn't support it
which I interpret as that the reptoline mitigates spectre v2 (only attacks on the kernel, right?) but that a microcode update is recommended for IBPB.
Shouldn't my first computer (the one with an Intel Celeron N2840 processor) have at least the same reptoline mitigation as my last computer? Shouldn't it also have the microcode mitigation as the middle computer?
debian security
edited Apr 21 at 11:38
asked Apr 20 at 19:46
arcus_mannen
184
184
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
For Skylake and newer processors, retpoline won't be enough to completely mitigate Spectre V2. I'm hazy as to how Bay Trail compares to the desktop processor generations, but it might be using predictive logic that is similar to Skylake's.
Also, although the microcode guidance PDF says the microcodes for Celeron Nxxxx series have been gone to "production", they did not seem to be included in the latest published Linux microcode file. Someone else is salty about that too:
https://communities.intel.com/thread/124308
Okay! Now it makes sense why my Celeron computer didn't get any new microcode. And despite having the same reptoline-software as my C2D computer, on the Celeron computer, that reptoline-software isn't enough while on the C2D it is? (If my Celeron uses similar logic to Skylake) Have I understood this correct?
â arcus_mannen
Apr 22 at 4:23
Yes: the more advanced the processor's predictive-execution logic is, the more tricky it will be to avoid the Spectre vulnerabilities, and so the retpoline code alone won't be enough on newer processors. (And it is indeed retpoline, short for return trampoline.)
â telcoM
Apr 22 at 7:10
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
For Skylake and newer processors, retpoline won't be enough to completely mitigate Spectre V2. I'm hazy as to how Bay Trail compares to the desktop processor generations, but it might be using predictive logic that is similar to Skylake's.
Also, although the microcode guidance PDF says the microcodes for Celeron Nxxxx series have been gone to "production", they did not seem to be included in the latest published Linux microcode file. Someone else is salty about that too:
https://communities.intel.com/thread/124308
Okay! Now it makes sense why my Celeron computer didn't get any new microcode. And despite having the same reptoline-software as my C2D computer, on the Celeron computer, that reptoline-software isn't enough while on the C2D it is? (If my Celeron uses similar logic to Skylake) Have I understood this correct?
â arcus_mannen
Apr 22 at 4:23
Yes: the more advanced the processor's predictive-execution logic is, the more tricky it will be to avoid the Spectre vulnerabilities, and so the retpoline code alone won't be enough on newer processors. (And it is indeed retpoline, short for return trampoline.)
â telcoM
Apr 22 at 7:10
add a comment |Â
up vote
1
down vote
accepted
For Skylake and newer processors, retpoline won't be enough to completely mitigate Spectre V2. I'm hazy as to how Bay Trail compares to the desktop processor generations, but it might be using predictive logic that is similar to Skylake's.
Also, although the microcode guidance PDF says the microcodes for Celeron Nxxxx series have been gone to "production", they did not seem to be included in the latest published Linux microcode file. Someone else is salty about that too:
https://communities.intel.com/thread/124308
Okay! Now it makes sense why my Celeron computer didn't get any new microcode. And despite having the same reptoline-software as my C2D computer, on the Celeron computer, that reptoline-software isn't enough while on the C2D it is? (If my Celeron uses similar logic to Skylake) Have I understood this correct?
â arcus_mannen
Apr 22 at 4:23
Yes: the more advanced the processor's predictive-execution logic is, the more tricky it will be to avoid the Spectre vulnerabilities, and so the retpoline code alone won't be enough on newer processors. (And it is indeed retpoline, short for return trampoline.)
â telcoM
Apr 22 at 7:10
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
For Skylake and newer processors, retpoline won't be enough to completely mitigate Spectre V2. I'm hazy as to how Bay Trail compares to the desktop processor generations, but it might be using predictive logic that is similar to Skylake's.
Also, although the microcode guidance PDF says the microcodes for Celeron Nxxxx series have been gone to "production", they did not seem to be included in the latest published Linux microcode file. Someone else is salty about that too:
https://communities.intel.com/thread/124308
For Skylake and newer processors, retpoline won't be enough to completely mitigate Spectre V2. I'm hazy as to how Bay Trail compares to the desktop processor generations, but it might be using predictive logic that is similar to Skylake's.
Also, although the microcode guidance PDF says the microcodes for Celeron Nxxxx series have been gone to "production", they did not seem to be included in the latest published Linux microcode file. Someone else is salty about that too:
https://communities.intel.com/thread/124308
answered Apr 21 at 15:36
telcoM
10.4k11032
10.4k11032
Okay! Now it makes sense why my Celeron computer didn't get any new microcode. And despite having the same reptoline-software as my C2D computer, on the Celeron computer, that reptoline-software isn't enough while on the C2D it is? (If my Celeron uses similar logic to Skylake) Have I understood this correct?
â arcus_mannen
Apr 22 at 4:23
Yes: the more advanced the processor's predictive-execution logic is, the more tricky it will be to avoid the Spectre vulnerabilities, and so the retpoline code alone won't be enough on newer processors. (And it is indeed retpoline, short for return trampoline.)
â telcoM
Apr 22 at 7:10
add a comment |Â
Okay! Now it makes sense why my Celeron computer didn't get any new microcode. And despite having the same reptoline-software as my C2D computer, on the Celeron computer, that reptoline-software isn't enough while on the C2D it is? (If my Celeron uses similar logic to Skylake) Have I understood this correct?
â arcus_mannen
Apr 22 at 4:23
Yes: the more advanced the processor's predictive-execution logic is, the more tricky it will be to avoid the Spectre vulnerabilities, and so the retpoline code alone won't be enough on newer processors. (And it is indeed retpoline, short for return trampoline.)
â telcoM
Apr 22 at 7:10
Okay! Now it makes sense why my Celeron computer didn't get any new microcode. And despite having the same reptoline-software as my C2D computer, on the Celeron computer, that reptoline-software isn't enough while on the C2D it is? (If my Celeron uses similar logic to Skylake) Have I understood this correct?
â arcus_mannen
Apr 22 at 4:23
Okay! Now it makes sense why my Celeron computer didn't get any new microcode. And despite having the same reptoline-software as my C2D computer, on the Celeron computer, that reptoline-software isn't enough while on the C2D it is? (If my Celeron uses similar logic to Skylake) Have I understood this correct?
â arcus_mannen
Apr 22 at 4:23
Yes: the more advanced the processor's predictive-execution logic is, the more tricky it will be to avoid the Spectre vulnerabilities, and so the retpoline code alone won't be enough on newer processors. (And it is indeed retpoline, short for return trampoline.)
â telcoM
Apr 22 at 7:10
Yes: the more advanced the processor's predictive-execution logic is, the more tricky it will be to avoid the Spectre vulnerabilities, and so the retpoline code alone won't be enough on newer processors. (And it is indeed retpoline, short for return trampoline.)
â telcoM
Apr 22 at 7:10
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f439008%2fthe-latest-intel-microcode-fail-to-install-on-debian-stretch%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password