Announcement

Collapse
No announcement yet.

Linux 5.15 Adds Another Knob To Harden Against Side Channel Attacks

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by tildearrow View Post
    Excuse me xfcemint... I am reading your replies several times and trying...
    Oh, I just figured out where the confusion comes from. In one my reply (4 replies above) I quoted both you and Weasel in the same post, so that might have been a little confusing.

    Comment


    • #62
      Originally posted by xfcemint View Post
      Of course, and again, Weasel didn't bother to read my long answer above, because if he had red it, he wouldn't have posted this utterly misleading answer of his.

      In fact, Weasel didn't even read the Stack Overflow answer, nor the actual question. But he linked to it (that's most important for him, an argument from authority).

      As for the answer on Stack Overflow that he links to, I just actually bothered to read it.

      The Stack Overflow question is not the same as the question posted here, tildearrow was asking here about avoiding SPECTRE, and the answer on Stack Overflow has nothing to do with SPECTRE.

      So, completely misses the point.
      Maybe you should re-read the quote since it had nothing to do with SPECTRE, and the answer I linked explains exactly that.

      Meanwhile you've yet to prove even 1 of your bullshit. Like, you make a lot of claims, where's your PROOF?

      Undo is obviously not a problem for anyone with a brain. As long as it is speculatively executing it clearly cannot commit yet, so discarding all of it is as easy as throwing all the temporary data. Because unlike you, most people don't consider "but it's in the cache now!" as "wrong" execution—caches are supposed to be fully transparent to the instructions and software. Because the result, whether it's in the cache or not, is still correct, and that's what matters. Not measuring timing or some other bullshit.

      Here's a quote explaining the 50% probability outlined:
      Fetching instructions from both paths into one or more of the caches reduces the effective capacity of the caches in general, because, typically, one of the paths will be executed much more frequently than the other (in some, potentially highly irregular, pattern).
      Time to put up some proof on your end buddy.
      Last edited by Weasel; 15 September 2021, 08:22 AM.

      Comment


      • #63
        Originally posted by Weasel View Post
        Maybe you should re-read the quote since it had nothing to do with SPECTRE, and the answer I linked explains exactly that.
        Tildearrrow asked a question about SPECTRE. The answer you linked to has nothing to do with SPECTRE. And, you have just confirmed that here.

        Originally posted by Weasel View Post
        Undo is obviously not a problem for anyone with a brain. As long as it is speculatively executing it clearly cannot commit yet, so discarding all of it is as easy as throwing all the temporary data. Because unlike you, most people don't consider "but it's in the cache now!" as "wrong" execution—caches are supposed to be fully transparent to the instructions and software. Because the result, whether it's in the cache or not, is still correct, and that's what matters.
        Most types of SPECTRE are based on modifications made by the CPU to the caches during speculative execution. It doesn't matter whether CPU "commits" the data or not, as long as the CPU modifies cache metadata during speculative execution.

        I agree with you that implementing "undo" is not a big problem, in your words: "Undo is obviously not a problem for anyone with a brain". But, CPU manufacturers have refused to implement a sufficiently thorough undo operation for getting rid of SPECTRE v1.

        That's exactly the most important part of my proposed solution to SPECTRE: thorough undo.

        Originally posted by Weasel View Post
        Meanwhile you've yet to prove even 1 of your bullshit. Like, you make a lot of claims, where's your PROOF?
        Originally posted by Weasel View Post
        Here's a quote explaining the 50% probability outlined:Time to put up some proof on your end buddy.
        LOL. Proofs in the crafts of CPU design and computer programming are very rare. Instead of proofs, there is TESTING, lot of testing, and there are "best practices" like: functional programming, RISC design, object oriented programming, KISS, etc...

        You also haven't posted any proofs. Why is that?
        Last edited by xfcemint; 15 September 2021, 04:11 PM.

        Comment


        • #64
          Originally posted by Weasel View Post
          Maybe you should re-read the quote since it had nothing to do with SPECTRE
          Originally posted by tildearrow View Post
          While doing speculative execution, why not do "paranoid" speculative execution?
          Weasel said: "Maybe you should re-read the quote since it had nothing to do with SPECTRE"

          The quote from Tildearrow: why not do "paranoid" speculative execution
          [in the sense: to avoid SPECTRE.]

          SPECTRE = SPeculative ExeCuTion vulnerability (a vulnerability based on speculative execution)
          Last edited by xfcemint; 15 September 2021, 03:58 PM.

          Comment


          • #65
            Originally posted by xfcemint View Post
            Tildearrrow asked a question about SPECTRE. The answer you linked to has nothing to do with SPECTRE. And, you have just confirmed that here.

            Most types of SPECTRE are based on modifications made by the CPU to the caches during speculative execution. It doesn't matter whether CPU "commits" the data or not, as long as the CPU modifies cache metadata during speculative execution.

            I agree with you that implementing "undo" is not a big problem, in your words: "Undo is obviously not a problem for anyone with a brain". But, CPU manufacturers have refused to implement a sufficiently thorough undo operation for getting rid of SPECTRE v1.

            That's exactly the most important part of my proposed solution to SPECTRE: thorough undo.
            You don't get it. It can do "paranoid" speculation of both paths, but how is that different than normal speculative execution, doing both paths at once?

            The answer is the same: it's a waste of resources, because it's the same thing as having a 50% prediction rate (you predict correctly all the time, but waste twice as many resources doing so). This is simple statistics.

            Why would "paranoid" speculative execution be any different? "paranoid" speculative buffers/caches aren't cheaper/more free than "normal" caches used in "normal" speculative execution. You're going to literally halve their effectiveness (also pipelines and execution units) by executing both paths at once. It doesn't matter if it's "paranoid" buffers or normal caches.

            Originally posted by xfcemint View Post
            LOL. Proofs in the crafts of CPU design and computer programming are very rare. Instead of proofs, there is TESTING, lot of testing, and there are "best practices" like: functional programming, RISC design, object oriented programming, KISS, etc...

            You also haven't posted any proofs. Why is that?
            Well I did, the link supplied earlier.

            I was referring to your post here: https://www.phoronix.com/forums/foru...60#post1278860

            Which requires proof because it's wrong. It has nothing to do with SPECTRE, as I said.

            Comment


            • #66
              Originally posted by Weasel View Post
              You don't get it. It can do "paranoid" speculation of both paths, but how is that different than normal speculative execution, doing both paths at once?

              The answer is the same: it's a waste of resources, because it's the same thing as having a 50% prediction rate (you predict correctly all the time, but waste twice as many resources doing so). This is simple statistics.

              It doesn't matter if it's "paranoid" buffers or normal caches.
              It doesn't matter if it's "paranoid" or "normal" speculative execution, but not because "it's a waste of resources" (your answer), but because "paranoid" speculative execution does nothing to fix SPECTRE.

              You are completely losing your mind, Weasel. It appears as if you don't know what we are talking about. For refreshing your memory, you should read again this post of mine:
              Originally posted by xfcemint View Post
              ((( My original answer which explains that "paranoid" speculative execution does not fix SPECTRE, and why is that so. )))

              Originally posted by Weasel View Post
              Well I did, the link supplied earlier.

              I was referring to your post here: https://www.phoronix.com/forums/foru...60#post1278860

              Which requires proof because it's wrong. It has nothing to do with SPECTRE, as I said.
              Yes, but that link only confirms that "paranoid" speculative execution is not high-performance. I agree with that, there is nothing wrong with that claim.

              However, we are discussing why "paranoid" speculative execution does not fix SPECTRE. So, you went in some kind of a wrong thinking direction.

              Comment


              • #67
                Originally posted by tildearrow View Post

                Excuse me xfcemint... I am reading your replies several times and trying to understand because I am not an expert in modern CPU design, so a response may take a while to be formulated.
                Let's fill this void a bit.

                So, tildearrow, do you like my design so far?

                In my mind, it's all relatively simple and straightforward.

                Don't be afraid, I bite only when people are mean to me.
                Last edited by xfcemint; 17 September 2021, 10:14 AM.

                Comment


                • #68
                  Originally posted by Weasel View Post
                  You don't get it. It can do "paranoid" speculation of both paths, but how is that different than normal speculative execution, doing both paths at once?
                  Sorry, Weasel, perhaps I was too harsh on you.

                  If you didn't comment and attack my design, I wouldn't have been able to explain it so clearly.

                  You do know a lot of things about computers and CPUs, but becoming a real expert requires a lot of effort: reading, learning, analyzing, studying. And, most people are not willing to put in such effort, or perhaps they just enjoy other things in life.

                  EDITED: grammatical mistakes
                  Last edited by xfcemint; 17 September 2021, 10:27 AM.

                  Comment


                  • #69
                    Originally posted by xfcemint View Post

                    Let's fill this void a bit.

                    So, tildearrow, do you like my design so far?

                    In my mind, it's all relatively simple and straightforward.

                    Don't be afraid, I bite only when people are mean to me.
                    Seems like a good idea.

                    Comment


                    • #70
                      Originally posted by tildearrow View Post

                      Seems like a good idea.
                      Well, thank you, I'm glad that you like it. And, thank you for the assistance so far.

                      Comment

                      Working...
                      X