Announcement

Collapse
No announcement yet.

Design of a SPECTRE-Resistant High-Performance CPU

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

  • #31
    Here is a better model:

    (correction) SEKILL instruction also removes the selected "DIRECTION" bit from the state of the CPU instance that executed the said SEKILL instruction.

    There is an instruction SEKILLALL that selects all the previous branching points, that is, all the remaining DIRECTION bits. If any of those bits equal "INCORRECT", the CPU+memory instance kills itself.

    To make the speculative and nonspeculative CPU 100% compatible, it is sufficient to execute SEKILLALL instruction at the end of the program code (at every leaf of the execution tree) and to disable any communication between instances.
    Last edited by xfcemint; 23 September 2021, 01:46 PM.

    Comment


    • #32
      Oh, I forgot the I/O instructions.

      Let's make the speculative CPU execute a SEKILLALL instruction just before it executes any I/O instruction. That is sufficient to make all I/O 100% compatible.

      Previously I have defined "external behavior in time", and that is about contents of the memory being the same in the speculative and nonspeculative version.

      To make "external behavior in time" identical for speculative and nonspeculative CPUs, it is sufficient to examine all CPU+memory instances of the speculative CPU and find the instance that has none of the remaining DIRECTION bits equal to "INCORRECT". There will always be exactly one such CPU+memory instance. The information stored in the memory attached to that CPU+memory instance is the one that is identical to the SPECTRE-proof nonspeculative version.
      Last edited by xfcemint; 23 September 2021, 01:47 PM.

      Comment


      • #33
        As I have just demonstrated, there exists a speculative CPU which is SPECTRE-proof.

        Now, lets demonstrate the existence of a SPECTRE-vulnerable CPU.

        To do this, it is sufficient to enable any communication between instances. Here is an example:
        - there is one light attached to the system, for example a NUM LOCK (NLOCK) light on the keyboard.
        - the keyboard can store the state of this light.
        - add to execution semantics one input and two output instructions: NLOCK-READ, NLOCK-ON, NLOCK-OFF.

        The rest is easy to imagine. Examine a short program:
        1: NLOCK-OFF
        2: IF 1=1 GOTO [END]
        3: NLOCK-ON
        4: [END]

        Which turns into this execution tree:
        Code:
                            / >>(YES)>> [END]
        NLOCK-OFF >>> IF 1=1
                            \>>(NO)>> NLOCK-ON >>> [END]
        On the speculative system the NUM LOCK light turns ON.
        On the nonspeculative system the NUM LOCK is always OFF.
        The different result on the NUM LOCK light indicates that the speculative system leaked information at the instruction 3, which is past the branching point at instruction 2. Instruction 2 could have been a security check, and the instruction 3 could have been part of a credit card number that the attacker wanted to read.

        As the modeled speculative system has obviously leaked information, it is SPECTRE-vulnerable.
        Last edited by xfcemint; 23 September 2021, 11:59 AM.

        Comment


        • #34
          Now, lets make the SPECTRE-vulnerable system to become SPECTRE-proof.

          1. Change the semantics of NLOCK-ON and NLOCK-OFF instructions so that the instruction SEKILLALL is executed just before.

          The program can now be written as:
          1: SEKILLALL, NLOCK-OFF
          2: IF 1=1 GOTO [END]
          3: SEKILLALL, NLOCK-ON
          4: [END]

          Now the speculative CPU is 100% compatible with the corresponding nonspeculative CPU.

          It follows:
          1. EVERY SPECTRE-proof CPU can be converted into a 100% compatible speculative CPU
          2. EVERY SPECTRE-proof execution semantics has a corresponding 100% compatible speculative execution semantics

          Comment


          • #35
            The title of this thread is Design of a SPECTRE-Resistant High-Performance CPU

            This thread so far demonstrates:
            - every nonspeculative CPU is SPECTRE-proof by definition.
            - for every imaginable nonspeculative CPU there exists a 100% compatible speculative CPU

            Since all of today's real CPUs have nonspeculative predecessors, a new speculative CPU can be designed that is 100% compatible with a nonspeculative SPECTRE-proof predecessor of any modern CPU.

            In other words, the desired SPECTRE-resistant CPU can employ speculative execution and remain SPECTRE-proof. This is a desirable property to be able to attain high-performance. As stated in the post #5:

            D2) uses SE (speculative execution)
            Last edited by xfcemint; 23 September 2021, 12:19 PM.

            Comment


            • #36
              Let's examine the validity of the two definitions I have posted earlier:

              Originally posted by xfcemint View Post
              A SPECTRE-proof CPU is a CPU whose external behavior in time can be implemented by an in-order-nonspeculative CPU connected to the memory of the same capacity, same external reference timer and the same keyboard.

              A SPECTRE-vulnerable CPU is a CPU whose external behavior in time cannot be implemeted by an in-order-nonspeculative CPU connected to the memory of the same capacity, same external reference timer and the same keyboard.

              SPECTRE definition 1: A microarchitectural CPU design error that converts a SPECTRE-proof CPU design into a SPECTRE-vulnerable CPU design.
              Let's define a constrained storage nonspeculative CPU as: a nonspeculative CPU that has internal information storage capacity constant in time and equal for any program, and exactly equal to the amount of information that can be transferred from it to the attached memory by any desired instruction sequence.

              In other words: there are no "hidden", "unreadable", "purposeless" or "delayed" bits of information in a constrained storage nonspeculative CPU.

              If all nonspeculative CPUs have constrained storage, then the definitions above seem to be meaningful.

              Even if some kind of "branch in both directions" instruction is added to the execution semantics, it won't help, because the nonspeculative CPU has insufficient internal storage capacity to perform speculative execution.
              Last edited by xfcemint; 23 September 2021, 04:02 PM.

              Comment


              • #37
                Lets define implementable CPU as: in-order nonspeculative CPU that has a constant-size finite internal storage (but "hidden" and "delayed" bits are allowed).

                Then this statement appears to be true: For every implementable CPU there exists a constrained storage in-order nonspeculative CPU that can emulate it (in the sense that external behavior in time and all I/O are the same, but the execution semantics may be different).

                This is different then the 100% compatibility between nonspeculative CPUs and certain speculative CPUs that I have described earlier, because in that case the speculative and nonspeculative semantics were essentially identical.
                Last edited by xfcemint; 23 September 2021, 05:52 PM.

                Comment


                • #38
                  So, those definitions are actually incorrect, because an implementable CPU can have sufficient storage capacity to perform speculative execution (as modern CPUs do).

                  Let's correct those definitions:
                  A SPECTRE-proof CPU is a CPU whose external behavior in time can be implemented by a constrained storage in-order-nonspeculative CPU connected to the memory of the same capacity, same external reference timer and the same keyboard.

                  A SPECTRE-vulnerable CPU is a CPU whose external behavior in time cannot be implemeted by a constrained storage in-order-nonspeculative CPU connected to the memory of the same capacity, same external reference timer and the same keyboard.

                  Comment


                  • #39
                    I think that some of the definitions I have written, and some of the phrases I have used are not exactly the most beautifully worded. Let's attempt to improve them:

                    Program: finite number of instructions organized in an execution tree valid by the execution semantics.

                    Total storage capacity of a nonspeculative CPU in a given system: The maximum amount of information that can be retrieved from the CPU to the attached memory after being stored to the CPU from the attached memory by any possible program.

                    Not every given system has a well-defined total storage capacity of the CPU, because the CPU can have a finite or an infinite storage capacity.

                    Let's correct the definition of implementable CPU to: in-order nonspeculative CPU that has a finite total storage capacity.

                    I am unable, at this moment, to think of a definition of some other sensible measure of CPU's information capacity. The implication is that there is a confusion in the definitions above. There is, apparently, no difference between implementable CPU and constrained-storage CPU. An implementable modern SE CPU does not perform speculative execution, instead it can be said that it emulates speculative execution.

                    Now it appears that the original definitions of SPECTRE-proof and SPECTRE-vulnerable CPUs were correct, and the new ones are just badly worded.

                    Comment


                    • #40
                      Also, the term "in-order" apparently has no distinctive meaning. It's just our imagination. All CPUs are in-order. Out-of-order CPUs don't exist, in my opinion, because execution semantics is always in-order.

                      Perhaps the term "out-of-order" can be perceived as a CPU design guideline (how to design a CPU), but not as a sensible difference between kinds of CPUs.
                      Last edited by xfcemint; 24 September 2021, 01:10 AM.

                      Comment

                      Working...
                      X