4 ms·

I'm certainly a fan of languages built for robustness and safety but this a CPU for (essentially) pedagogy purposes. A b5000-esque cpu would be much less straig

I'm certainly a fan of languages built for robustness and safety but this a CPU for (essentially) pedagogy purposes. A b5000-esque cpu would be much less straight forward (actually I don't even know how many of the b5000's features were in the cpu vs being in some other support chip)

nickpsecurity 10y ago
"but this a CPU for (essentially) pedagogy purposes" No doubt. Many people might try to build on it for other reasons. Hence, my warning. "A b5000-esque cpu would be much less straight forward" Try crash-safe.org's main presentation on SAFE architecture. Narrow your focus to that one section on atomic groups. Mentally combine that with Burrough's most primitive checks. I'm talking code vs data check, pointer bounds check, pointer write-check to prevent modification, optionally stack overflow, and so on. Each one is a few lines of C code if you draw it out. I don't design HW but I've read enough of these to know there's close to zero performance and gate overhead in such simple checks. They typically run in parallel with CPU pipeline where it goes ahead with execution but doesn't actually write results unless gets a "1" (check succeeds) from parallel checkers. Simple, simple. Academics with almost no team or budget typically start with highly-configurable, Leon3 CPU. They add the tags or checks into a few components. Synthesize for FPGA. Done. Then, compiler and/or OS modifications to make use of it. I've seen it done for RTEMS and Linux with small teams and mods. Cambridge's CHERI, with larger team, did whole capability-architecture that's C compatible and runs FreeBSD port. Changes that big have quite the performance implications, though, which is why I focus on primitive checks for interim or hobbyist use. ;)
- pjmlp 10y ago
  Looking forward to the day that all x86 code is MPX enabled. :)
  - nickpsecurity 10y ago
    It's a nice start and improvement. I'd like to see more peer review on stuff like Hardbound and Code-pointer Integrity. I think stuff like Softbound or Code-pointer integrity could be merged with MPX to reduce its cost. Or just amplify its capability. Would be worthwhile research for some undergrads seeing as MPX is deployed already.
- dewster 10y ago
  > I'm talking code vs data check, pointer bounds check, pointer write-check to prevent modification, optionally stack overflow, and so on. I'm probably showing my ignorance, but I don't think anyone can convince me that in a perfect world software errors should be caught by dedicated hardware. Same with pushing software security issues to the HW. SW needs a pottery barn rule, you broke it you pay for it. The HW is already too complicated as it is.
  - nickpsecurity 10y ago
    "SW needs a pottery barn rule, you broke it you pay for it." Software, even small stuff, has proven to be too complex to get right consistently except for the most, elite programmers. A safety net or safe by default makes more sense. It's more fundamental than that, though. You see, certain languages in programming are closer to how we think and express our ideas as people. We find we get more productive as we abstract away from the machine. Yet, stuff close to machine is most efficient. Common machine designs were pretty arbitrary: alternatives existed with benefits. Market forces caused proliferation of specific, painful architectures. So, the right thing seems to be to raise abstraction of underlying machine while modifying architecture to express safe or secure programs naturally. For instance, you don't want out of bounds pointers, overflowing stacks, or data treated as code. So, why does your CPU allow that in the first place all over memory and program code? Just foolish. Instead, design the CPU to include compiler-calculated bounds with pointers, to spot stack overflows in making, and to mark & treat differently code vs data. That's what Burroughs did and SAFE is doing. Another is modular programming and OOP's takeover of modern programming. Our systems are broken down into modules with internal state, function calls operating on it, and function calls to other modules. We enforce separation between these states, expect some functions/data to stay private, and expect certain datatypes in function calls. Object-descriptor architectures divide hardware into objects with read/write/execute/access permissions enforced as CPU runs the program. Natural way to express such a system. Mapping OOP expressions & procedures onto a stack, heap, user/kernel MMU, and optionally some segments doesn't fit the use case at all. Alien to it actually. So, the idea is to combine a language for efficient, productive, and safe-by-default expression of our intent as programmers with a CPU designed to efficiently run that plus provide low-cost checks as a safety net. That was Burroughs approach. An embedded version might be combination of Java subset with Java CPU's like jop-design.com or Sandia's Secure Processor (aka SSP or Score). Java CPU runs hardware ideal for language with some basic checks built-in that run at high speed. Language, type system, static analysis, compiler, and programmer do rest. So, two different models. One is arbitrary machines designed for whatever Thompson or Moore preferred on minimal hardware they had with "just try harder" told to programmers. Other is carefully-designed, safe languages with CPU's built for them & checking their integrity. Option 2 makes more sense to me even if minority opinion. ;)

nickpsecurity 10y ago

"but this a CPU for (essentially) pedagogy purposes" No doubt. Many people might try to build on it for other reasons. Hence, my warning. "A b5000-esque cpu would be much less straight forward" Try crash-safe.org's main presentation on SAFE architecture. Narrow your focus to that one section on atomic groups. Mentally combine that with Burrough's most primitive checks. I'm talking code vs data check, pointer bounds check, pointer write-check to prevent modification, optionally stack overflow, and so on. Each one is a few lines of C code if you draw it out. I don't design HW but I've read enough of these to know there's close to zero performance and gate overhead in such simple checks. They typically run in parallel with CPU pipeline where it goes ahead with execution but doesn't actually write results unless gets a "1" (check succeeds) from parallel checkers. Simple, simple. Academics with almost no team or budget typically start with highly-configurable, Leon3 CPU. They add the tags or checks into a few components. Synthesize for FPGA. Done. Then, compiler and/or OS modifications to make use of it. I've seen it done for RTEMS and Linux with small teams and mods. Cambridge's CHERI, with larger team, did whole capability-architecture that's C compatible and runs FreeBSD port. Changes that big have quite the performance implications, though, which is why I focus on primitive checks for interim or hobbyist use. ;)

pjmlp 10y ago
Looking forward to the day that all x86 code is MPX enabled. :)
- nickpsecurity 10y ago
  It's a nice start and improvement. I'd like to see more peer review on stuff like Hardbound and Code-pointer Integrity. I think stuff like Softbound or Code-pointer integrity could be merged with MPX to reduce its cost. Or just amplify its capability. Would be worthwhile research for some undergrads seeing as MPX is deployed already.
dewster 10y ago
> I'm talking code vs data check, pointer bounds check, pointer write-check to prevent modification, optionally stack overflow, and so on. I'm probably showing my ignorance, but I don't think anyone can convince me that in a perfect world software errors should be caught by dedicated hardware. Same with pushing software security issues to the HW. SW needs a pottery barn rule, you broke it you pay for it. The HW is already too complicated as it is.
- nickpsecurity 10y ago
  "SW needs a pottery barn rule, you broke it you pay for it." Software, even small stuff, has proven to be too complex to get right consistently except for the most, elite programmers. A safety net or safe by default makes more sense. It's more fundamental than that, though. You see, certain languages in programming are closer to how we think and express our ideas as people. We find we get more productive as we abstract away from the machine. Yet, stuff close to machine is most efficient. Common machine designs were pretty arbitrary: alternatives existed with benefits. Market forces caused proliferation of specific, painful architectures. So, the right thing seems to be to raise abstraction of underlying machine while modifying architecture to express safe or secure programs naturally. For instance, you don't want out of bounds pointers, overflowing stacks, or data treated as code. So, why does your CPU allow that in the first place all over memory and program code? Just foolish. Instead, design the CPU to include compiler-calculated bounds with pointers, to spot stack overflows in making, and to mark & treat differently code vs data. That's what Burroughs did and SAFE is doing. Another is modular programming and OOP's takeover of modern programming. Our systems are broken down into modules with internal state, function calls operating on it, and function calls to other modules. We enforce separation between these states, expect some functions/data to stay private, and expect certain datatypes in function calls. Object-descriptor architectures divide hardware into objects with read/write/execute/access permissions enforced as CPU runs the program. Natural way to express such a system. Mapping OOP expressions & procedures onto a stack, heap, user/kernel MMU, and optionally some segments doesn't fit the use case at all. Alien to it actually. So, the idea is to combine a language for efficient, productive, and safe-by-default expression of our intent as programmers with a CPU designed to efficiently run that plus provide low-cost checks as a safety net. That was Burroughs approach. An embedded version might be combination of Java subset with Java CPU's like jop-design.com or Sandia's Secure Processor (aka SSP or Score). Java CPU runs hardware ideal for language with some basic checks built-in that run at high speed. Language, type system, static analysis, compiler, and programmer do rest. So, two different models. One is arbitrary machines designed for whatever Thompson or Moore preferred on minimal hardware they had with "just try harder" told to programmers. Other is carefully-designed, safe languages with CPU's built for them & checking their integrity. Option 2 makes more sense to me even if minority opinion. ;)