Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Wednesday January 17 2018, @07:51PM   Printer-friendly
from the oughta-be-a-law dept.

Vox Media website theverge.com reports that Rep. Jerry McNerney (D-CA) wants answers about the recent computer chip chaos.

Congress is starting to ask hard questions about the fallout from the Meltdown and Spectre vulnerabilities. Today, Rep. Jerry McNerney (D-CA) sent a letter [(pdf)] requesting a briefing from Intel, AMD, and ARM about the vulnerabilities’ impact on consumers.

[...] The two vulnerabilities are “glaring warning signs that we must take cybersecurity more seriously,” McNerney argues in the letter. “Should the vulnerabilities be exploited, the effects on consumers’ privacy and our nation’s economy and security would be absolutely devastating.”

Privately disclosed to chipmakers in June of 2016, the Meltdown and Spectre bugs became public after a haphazard series of leaks earlier this month. In the aftermath, there have been significant patching problems, including an AMD patch that briefly prevented Windows computers from booting up. Intel in particular has come under fire for inconsistent statements about the impact of the bugs, and currently faces a string of proposed class-action lawsuits relating to the bugs.

Meltdown can be fixed through a relatively straightforward operating-system level patch, but Spectre has proven more difficult, and there have been significant patching problems in the aftermath. The most promising news has been Google’s Retpoline approach, which the company says can protect against the trickiest Spectre variant with little negative performance impact.

The letter calls on the CEOs of Intel, AMD, and ARM to answer (among other things) when they learned about these problems and what they are doing about it.


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: 2) by DannyB on Wednesday January 17 2018, @09:49PM (4 children)

    by DannyB (5839) Subscriber Badge on Wednesday January 17 2018, @09:49PM (#623833) Journal

    I agree with you about both Spectre and Meltdown. Got to have speculative execution. But why leak timing info for memory you aren't allowed to fondle.

    But this is the biggest insight in what you said, and I don't have mod points left:

    We'll never know, but that's what we'll have to live with as long as proprietary hardware with secret, closed design/development/fabrication is the only feasible option.

    That is a profound concern. As systems grow ever more complex, instead of more simple and open, we can never be sure that there isn't a small thermal exhaust port that can lead to the destruction of the entire death star.

    And we still have to worry about software binary problems like "Trusting Trust". Can you be sure the binary of your C compiler isn't compromised even though the source code appears clean, but recompiling the clean source with the compromised compiler will bake the compromise into the newly compiled compiler.

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by DannyB on Wednesday January 17 2018, @10:02PM

    by DannyB (5839) Subscriber Badge on Wednesday January 17 2018, @10:02PM (#623846) Journal

    I wrote it after this comment, but further down is a hypothetical type of invalid opcode compromise that could be baked into a microprocessor.

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.
  • (Score: 0) by Anonymous Coward on Wednesday January 17 2018, @10:02PM (2 children)

    by Anonymous Coward on Wednesday January 17 2018, @10:02PM (#623847)

    > And we still have to worry about software binary problems like "Trusting Trust"

    There's David A. Wheeler's proposed solution for that: Diverse Double Compilation [dwheeler.com] where you take your suspect compiler's clean sources, and build them with itself (A) and another, unlikely-to-be-malicious-in-the-same-manner compiler (B). You get C and D, respectively. They're different binaries (built with different compilers, duh), but they're the *same* functionality (same source specifying what they do). So, for identical inputs, C and D should produce identical outputs.

    Now, we compile the clean A sources again, with C and D. Same input should give us identical binary output. If the original A binary was clean, then C should have been clean, thus the output of C should match the (clean) output of D. If they don't, you can tell it's time to start hand-assembling your sources :)

    • (Score: 2) by DannyB on Wednesday January 17 2018, @10:16PM (1 child)

      by DannyB (5839) Subscriber Badge on Wednesday January 17 2018, @10:16PM (#623854) Journal

      Yes. That is why it would be good to have a number of C compilers written in other languages. Especially a few written in interpreted languages. Python. JavaScript. Lisp. Etc. (Even if JIT'ed) These C compilers aren't meant to be fast or to generate great code. They are merely intended to work and provide a diversity of C compilers that also happen to run on many hardware platforms. I'm sure you can find a way to compile your target compiler using multiple of these compilers on multiple platforms. Then take those resulting binaries and re-compile your target compiler with each of those binaries which should generate identical optimized binaries of your target compiler.

      --
      People today are educated enough to repeat what they are taught but not to question what they are taught.
      • (Score: 0) by Anonymous Coward on Thursday January 18 2018, @06:46PM

        by Anonymous Coward on Thursday January 18 2018, @06:46PM (#624286)
        This was the subject of a Ph.D. Thesis, called Double Diverse Compiling. You can read about it at https://www.dwheeler.com/trusting-trust/ [dwheeler.com]