Announcement

Collapse
No announcement yet.

GNU Linux-Libre 4.16 Released, Won't Warn You About Spectre/Meltdown Microcode Updates

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    lilos
    Junior Member

  • lilos
    replied
    Originally posted by admax88 View Post
    For more details:

    https://security.googleblog.com/2018...for-cpu_4.html

    Variant 1 can be mitigated by recompilation

    Variant 2 can be mitigated by firmware updates _OR_ retpoline

    Variant 3 can be mitigated via KPTI.

    As a result linux-libre is fine.
    And why linux-libre did not come with this fixes by default ?

    How we can patch CVE-2017-5753 aka 'Spectre Variant 2'
    with redpoline i don`t want to use intel microcode update!


    ################################################3

    Checking for vulnerabilities on current system
    Kernel is Linux 4.16.0-gnu #1 SMP Mon Apr 2 00:58:20 UTC 2018 x86_64
    CPU is Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz

    Hardware check
    * Hardware support (CPU microcode) for mitigation techniques
    * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available: NO
    * CPU indicates IBRS capability: NO
    * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available: NO
    * CPU indicates IBPB capability: NO
    * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available: NO
    * CPU indicates STIBP capability: NO
    * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability: NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
    * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
    * CPU microcode is known to cause stability problems: NO (model 23 stepping 10 ucode 0xa07)
    * CPU vulnerability to the three speculative execution attack variants
    * Vulnerable to Variant 1: YES
    * Vulnerable to Variant 2: YES
    * Vulnerable to Variant 3: YES

    CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
    * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
    * Kernel has array_index_mask_nospec (x86): YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
    * Kernel has the Red Hat/Ubuntu patch: NO
    * Kernel has mask_nospec64 (arm): NO
    > STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

    CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
    * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
    * Mitigation 1
    * Kernel is compiled with IBRS/IBPB support: YES
    * Currently enabled features
    * IBRS enabled for Kernel space: UNKNOWN
    * IBRS enabled for User space: UNKNOWN
    * IBPB enabled: UNKNOWN
    * Mitigation 2
    * Kernel has branch predictor hardening (arm): NO
    * Kernel compiled with retpoline option: YES
    * Kernel compiled with a retpoline-aware compiler: NO (kernel reports minimal retpoline compilation)
    > STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline)

    CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
    * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
    * Kernel supports Page Table Isolation (PTI): YES (found 'CONFIG_PAGE_TABLE_ISOLATION=y')
    * PTI enabled and active: YES
    * Running as a Xen PV DomU: NO
    > STATUS: NOT VULNERABLE (Mitigation: PTI)



    lilos
    Junior Member
    Last edited by lilos; 05 April 2018, 05:48 AM.

    Leave a comment:

  • Delgarde
    Senior Member

  • Delgarde
    replied
    Originally posted by tpruzina
    Think they are doing disservice to their customers by not shipping blobs, if you have a choice between stock microcode that is known to be insecure and updated microcode that is known to implement mitigatio, choice should be fairly simple really. Purism is a nice ideal to strive for, but in the mean time choose lesser evil, please.
    Out of curiosity, who do you think the customers (or lets say "users", since nobody is paying for it) are? Hint – they're the same kind of die-hard purists that would create a distro like this... they're not the kind of person who's going to be put off by a distro choosing ideology over practicality...

    Leave a comment:

  • unixfan2001
    Senior Member

  • unixfan2001
    replied
    Originally posted by starshipeleven View Post
    The point here is that microcode is running anyway, inhibiting the update of what is loaded from UEFI or the ROM does not prove anything.

    But it sure is easy.

    Just delete code and brand yourself as "defender of FOSS" or something.

    This is all bullshit I could do in 10 minutes myself by just deleting the firmware packages from my running system, and then rebooting.

    How about they do something more useful than just deleting code?

    Something that actually gives me hardware that respects my freedom instead of doing stupid cheap stunts that serve no purpose?

    Is this all FSF has become? A PETA equivalent for free software?
    I could actually see them "adopt" (as in, accept as donations) old hardware only to secretly smash it to bits behind people's backs.
    Just as PETA will murder animals under their care. Supposedly, to prove a "point" (though what point exactly ... only they and their fellow psychopaths know or understand).

    Leave a comment:

  • starshipeleven
    Premium Supporter

  • starshipeleven
    replied
    Originally posted by WolfpackN64 View Post
    No this is not all the FSF has become. Don't be daft.

    "Well, we are waiting."

    Don't leave me hanging like this.

    Leave a comment:

  • WolfpackN64
    Senior Member

  • WolfpackN64
    replied
    Originally posted by starshipeleven View Post
    The point here is that microcode is running anyway, inhibiting the update of what is loaded from UEFI or the ROM does not prove anything.

    But it sure is easy.

    Just delete code and brand yourself as "defender of FOSS" or something.

    This is all bullshit I could do in 10 minutes myself by just deleting the firmware packages from my running system, and then rebooting.

    How about they do something more useful than just deleting code?

    Something that actually gives me hardware that respects my freedom instead of doing stupid cheap stunts that serve no purpose?

    Is this all FSF has become? A PETA equivalent for free software?
    No this is not all the FSF has become. Don't be daft.

    Leave a comment:

  • starshipeleven
    Premium Supporter

  • starshipeleven
    replied
    Originally posted by tpruzina
    Think they are doing disservice to their customers by not shipping blobs, if you have a choice between stock microcode that is known to be insecure and updated microcode that is known to implement mitigatio, choice should be fairly simple really. Purism is a nice ideal to strive for, but in the mean time choose lesser evil, please.
    As others said, microcode updates aren't required to mitigate this particular case, so in this specific case it's not an issue.

    Overall, I agree with you, you cannot run without microcode and running with outdated microcodes does not make your system more less free or freedom-respecting. It's like painting the fence yellow and then claiming that the yellow fence makes your PC respect your freedom more. Does not change anything.

    Leave a comment:

  • starshipeleven
    Premium Supporter

  • starshipeleven
    replied
    Originally posted by WolfpackN64 View Post
    The FSF has always promoted extreme solutions because someone needs to show people just how much proprietary code runs on their systems. It's not a pragmatic approach, but no one expects it to be.
    The point here is that microcode is running anyway, inhibiting the update of what is loaded from UEFI or the ROM does not prove anything.

    But it sure is easy.

    Just delete code and brand yourself as "defender of FOSS" or something.

    This is all bullshit I could do in 10 minutes myself by just deleting the firmware packages from my running system, and then rebooting.

    How about they do something more useful than just deleting code?

    Something that actually gives me hardware that respects my freedom instead of doing stupid cheap stunts that serve no purpose?

    Is this all FSF has become? A PETA equivalent for free software?

    Leave a comment:

  • waxhead
    Premium For Life

  • waxhead
    replied
    Originally posted by tpruzina
    Think they are doing disservice to their customers by not shipping blobs, if you have a choice between stock microcode that is known to be insecure and updated microcode that is known to implement mitigatio, choice should be fairly simple really. Purism is a nice ideal to strive for, but in the mean time choose lesser evil, please.
    Give the FSF a break. Some of them might be fanatic , but then again many of us here are fanatic about Linux, some filesystem, some programs. some harddisk brands etc etc...
    There are far worse things in the world happening because of fanatics who even cut peoples head off, so for some to try to push for an ideal world where knowledge is shared (yes, programs are knowledge) is not really that bad is it?

    Just imagine if Wikipedia suddenly closed for example? Let's be glad that someone tries to share knowledge for free. And besides, FSF made their goal right? Now people are talking about they not warning against vulnerable hardware which in itself is just one more reason to open up the code.

    I will admit that they could have put up a warning. "hey, your hardware sucks, and because someone is not as idealistic as we are, we can't fix it either", that would have made more sense, but at least they get people talking until we are all on RISC-V hardware

    Leave a comment:

  • R41N3R
    Senior Member

  • R41N3R
    replied
    Originally posted by Mystro256 View Post
    So rather than suggesting to update the non-free FW to something more secure, it would rather you stick with the old, less secure non-free FW that comes on the chip because suggesting a non-free firmware update would violate your freedom?

    The logic seems incoherent to me.

    EDIT: Better solution, rather than remove it, change the warning to something noting the HW is vulnerable.
    Yes, it would have been better to warn the user that the non-free firmware of the specific hardware is vulnerable.

    Leave a comment:

  • iugamarian
    Junior Member

  • iugamarian
    replied
    Actually doing a firmware update on a Core I5-6400 disables (protect CPU from) the ability to overclock it by BCLK on Z170 board that has an older BIOs to allow it. And as admax88 and dungeon show you can be secure without firmware updates. So I actually really badly don't need firmware updates. BCLK overclock gives a stable 150% increase in CPU performance, can go up to 180% but it's then too stressed.

    Leave a comment:

Working...
X