O forse no: https://access.redhat.com/security/vulnerabilities/ssbdrik70 ha scritto:Ok, allora c'è qualcosa che non torna nel test.
Mi sembra di capire che le patch del kernel ci sono ma manca il microcode, come avevamo detto qualche post addietro.
Moderatore: Staff
O forse no: https://access.redhat.com/security/vulnerabilities/ssbdrik70 ha scritto:Ok, allora c'è qualcosa che non torna nel test.
Codice: Seleziona tutto
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: YES
> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)
CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports speculation store bypass: YES (found in /proc/self/status)
> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
Confermo con kernel 4.17.0 e nuovo microcoderik70 ha scritto:Mi sa che ci siamo:
Linux* Processor Microcode Data File
Version: 20180807 (Latest) Date: 8/7/2018
Codice: Seleziona tutto
CVE-2018-3640 [rogue system register read] aka 'Variant 3a' * CPU microcode mitigates the vulnerability: YES > STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability) CVE-2018-3639 [speculative store bypass] aka 'Variant 4' * Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp) * Kernel supports speculation store bypass: YES (found in /proc/self/status) > STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
Codice: Seleziona tutto
/lib/firmware/intel-ucode/
/lib/firmware/intel-ucode/06-0e-08
/lib/firmware/intel-ucode/06-0d-06
/lib/firmware/intel-ucode/06-0b-01
/lib/firmware/intel-ucode/06-56-05
/lib/firmware/intel-ucode/0f-03-03
/lib/firmware/intel-ucode/06-09-05
/lib/firmware/intel-ucode/06-3a-09
/lib/firmware/intel-ucode/0f-00-0a
/lib/firmware/intel-ucode/06-2d-07
/lib/firmware/intel-ucode/06-8e-09
/lib/firmware/intel-ucode/0f-04-08
/lib/firmware/intel-ucode/06-5f-01
/lib/firmware/intel-ucode/06-2c-02
/lib/firmware/intel-ucode/0f-04-01
/lib/firmware/intel-ucode/06-0b-04
/lib/firmware/intel-ucode/0f-04-0a
/lib/firmware/intel-ucode/06-1e-05
/lib/firmware/intel-ucode/0f-03-02
/lib/firmware/intel-ucode/06-3e-07
.....
/lib/firmware/intel-ucode-with-caveats/
/lib/firmware/intel-ucode-with-caveats/06-4f-01
Codice: Seleziona tutto
sudo iucode_tool -v --write-earlyfw=/boot/intel-ucode.cpio /lib/firmware/intel-ucode{,-with-caveats}
Codice: Seleziona tutto
MICROCODE_ARCH="/boot/intel-ucode.cpio"
Codice: Seleziona tutto
mkinitrd --altrevostreopzioni -P /boot/intel-ucode.cpio
Codice: Seleziona tutto
#!/bin/sh
# Do mkinitrd
mkinitrd -F
# If ok grub
if [ "$?" == "0" ]
then
grub-mkconfig -o /boot/grub/grub.cfg
else
echo "error!"
exit 1
fi
Codice: Seleziona tutto
[mer ago 8 20:36:45 2018] microcode: microcode updated early to revision 0x24, date = 2018-04-02
[mer ago 8 20:36:48 2018] microcode: sig=0x40651, pf=0x40, revision=0x24
[mer ago 8 20:36:48 2018] microcode: Microcode Update Driver: v2.2.
Una curiosità: sei sicuro che quell'opzione venga presa durante la generazione del config di grub?Meskalamdug ha scritto:GRUB_EARLY_INITRD_LINUX_CUSTOM="intel-ucode.cpio"
Codice: Seleziona tutto
iucode_tool -v --write-earlyfw=/boot/intel-ucode.cpio /lib/firmware/intel-ucode{,-with-caveats}
ma forse non è indispensabile.-- intel-ucode-with-caveats/ --
This directory holds microcode that might need special handling.
BDX-ML microcode is provided in directory, because it need special commits in
the Linux kernel, otherwise, updating it might result in unexpected system
behavior.
OS vendors must ensure that the late loader patches (provided in
linux-kernel-patches\) are included in the distribution before packaging the
BDX-ML microcode for late-loading.
Forse perché è meglio che venga caricato il prima possibile?conraid ha scritto:Io continuo a non capire perché usare questa procedura invece del semplice echo come consiglia Intel stessa.
Pericolo del bug tra l'init e rc.local?
Che per i server sia meglio l'altro metodo?In situations when the BIOS update isn't available, early loading
is the next best alternative to updating processor microcode. Microcode states
are reset on a power reset, hence its required to be updated everytime during
boot process.
Loading microcode using the initrd method is recommended so that the microcode
is loaded at the earliest time for best coverage. Systems that cannot tolerate
downtime may use the late reload method to update a running system without a
reboot.
L'opzione di grub potrebbe essere superflua,qui comunque funziona e parte tutto,appena posso la levo,faccio un test e vi faccio sapere.rik70 ha scritto:Una curiosità: sei sicuro che quell'opzione venga presa durante la generazione del config di grub?Meskalamdug ha scritto:GRUB_EARLY_INITRD_LINUX_CUSTOM="intel-ucode.cpio"
Sulla slack 14.2 ad esempio no.
Se invece da te la prende, nel grub.cfg generato dovresti vedere 2 initrd - quello relativo kernel e quello del microcode intel(inserito per primo).
Mi pare di capire poi che tu usi un'opzione di mkinitrd che include il microcode all'interno dell'initramfs. Se è così, allora non dovresti aver bisogno della parte relativa al config di grub.
Infine:
hai provato a generare l'archivio del microcode in questo modo:?Codice: Seleziona tutto
iucode_tool -v --write-earlyfw=/boot/intel-ucode.cpio /lib/firmware/intel-ucode{,-with-caveats}
Credo sia necessario per andare a pescare anche nella directory 'intel-ucode-with-caveats'ma forse non è indispensabile.-- intel-ucode-with-caveats/ --
This directory holds microcode that might need special handling.
BDX-ML microcode is provided in directory, because it need special commits in
the Linux kernel, otherwise, updating it might result in unexpected system
behavior.
OS vendors must ensure that the late loader patches (provided in
linux-kernel-patches\) are included in the distribution before packaging the
BDX-ML microcode for late-loading.