Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday January 19 2018, @01:39PM   Printer-friendly
from the tell-us-how-you-REALLY-think dept.

SoylentNews first reported the vulnerabilities on January 3. Since then, we have had a few stories addressing different reports about these vulnerabilities. Now that it is over two weeks later and we are *still* dealing with reboots, I am curious as to what our community's experience has been.

What steps have you taken, if any, to deal with these reports? Be utterly proactive and install every next thing that comes along? Do a constrained roll out to test a system or two before pushing out to other systems? Wait for the dust to settle before taking any steps?

What providers (system/os/motherboard/chip) have been especially helpful... or non-helpful? How has their response affected your view of that company?

What resources have you been using to check on the status of fixes for your systems? Have you found a site that stands above the others in timeliness and accuracy?

How has this affected your purchasing plans... and your expectations on what you could get for selling your old system? Are you now holding off on purchasing something new?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Friday January 19 2018, @09:14PM (2 children)

    by Anonymous Coward on Friday January 19 2018, @09:14PM (#624906)

    Does anyone have "proof of exploit code" for meltdown for Intel CPUs?

    I would like to test Intel P4 Prescott era CPUs. I see the "CPUs since 1995" quoted, but have P4s really been tested?

    For internet access I use a customized Linux live image booted from a USB key. So every power cycle gives me a "fresh install".

  • (Score: 2) by RS3 on Saturday January 20 2018, @01:49AM

    by RS3 (6367) on Saturday January 20 2018, @01:49AM (#625002)

    "fliptop" posted this earlier in this discussion:

    https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh [githubusercontent.com]

    I tried it on an older P4, and on some P3s and they are all vulnerable:

    Spectre and Meltdown mitigation detection tool v0.31

    Checking for vulnerabilities against running kernel Linux 4.14.14-1.el6.elrepo.i686 #1 SMP Wed Jan 17 13:21:40 EST 2018 i686
    CPU is Intel(R) Celeron(R) CPU 2.40GHz

    CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
    * Checking whether we're safe according to the /sys interface: NO (kernel confirms your system is vulnerable)
    > STATUS: VULNERABLE (Vulnerable)

    CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
    * Checking whether we're safe according to the /sys interface: NO (kernel confirms your system is vulnerable)
    > STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline)

    CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
    * Checking whether we're safe according to the /sys interface: NO (kernel confirms your system is vulnerable)
    > STATUS: VULNERABLE (Vulnerable)

    Spectre and Meltdown mitigation detection tool v0.31

    Checking for vulnerabilities against running kernel Linux 3.2.87-1.el5.elrepo #1 SMP PREEMPT Thu Mar 16 13:08:33 EDT 2017 i686
    CPU is Pentium III (Coppermine)

    CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
    * Checking count of LFENCE opcodes in kernel: NO
    > STATUS: VULNERABLE (only 17 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

    CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
    * Mitigation 1
    * Hardware (CPU microcode) support for mitigation
    * The SPEC_CTRL MSR is available: NO
    * The SPEC_CTRL CPUID feature bit is set: NO
    * Kernel support for IBRS: NO
    * IBRS enabled for Kernel space: NO
    * IBRS enabled for User space: NO
    * Mitigation 2
    * Kernel compiled with retpoline option: NO
    * Kernel compiled with a retpoline-aware compiler: NO
    > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

    CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
    * Kernel supports Page Table Isolation (PTI): NO
    * PTI enabled and active: NO
    * Checking if we're running under Xen PV (64 bits): NO
    > STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)

  • (Score: 0) by Anonymous Coward on Sunday January 21 2018, @06:39AM

    by Anonymous Coward on Sunday January 21 2018, @06:39AM (#625542)

    I was actually referring to the exploit code, not the patch checker.

    So i used this:
        https://github.com/paboldin/meltdown-exploit [github.com]

    When I run on a P4 prescott 630, I have to run the exploit code somewhere between 200 and 2000 times to get it to show the correct "stolen" data and even then, not all bytes are correct. So my conclusion is that P4s of that vintage theoretically have the vulnerability, but its not reliable enough to steal much data.

    I ran using the same linux live USB key on different machines with the same exact 32 bit executable. To verify that the executable could work, I ran it on an Intel i5-2520M and it showed the vulnerability every time for about 30 runs (all "stolen" bytes correct).

    The link above also has lists of VULNERABLE and NOT VULNERABLE cpus -- see the issues 19 and 22.