4 ms·

So, in other words, a tagged architecture, except the possible values of the tags are "usable" and "not usable"? Sounds horrible - it's the hardware equivalent

So, in other words, a tagged architecture, except the possible values of the tags are "usable" and "not usable"? Sounds horrible - it's the hardware equivalent of checking at runtime whether a variable is in scope in, say, Python or JavaScript. I don't see any point to checking at runtime what can be known statically.

nickpsecurity 11y ago
The tags are more commonly a few types like scaler, array, pointer w/ bounds, and so on. It checks basic stuff rather than full heap safety. Too tired to remember if there's one on that. The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The basics that go the furthest cost little to nothing in many designs. Then, you can go from there in your language or compiler design.
- catnaroek 11y ago
  > The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous.
  - nickpsecurity 11y ago
    "The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous." I think we have a different definition of unsafe. If you think it's potential to cause problems, then I agree it doesn't make it less unsafe. Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system. That's what I'm claiming. Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly.
    - catnaroek 11y ago
      > I think we have a different definition of unsafe. “Potentially without useful meaning”, e.g., indexing an array without knowing whether the the index is within bounds. > Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system. Your kid (your data) attends the same school as a bully (your program). One day, the bully threatens to punch your kid in the face (raises an exception). “But it's less wrong because he never punched your kid! He only threatened it!” > Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly. As long as the assembly code has the same meaning as the safe program from which it was generated, it's safe.
      - nickpsecurity 11y ago
        "Your kid (your data) attends the same school as a bully (your program). One day, the bully threatens to punch your kid in the face (raises an exception). “But it's less wrong because he never punched your kid! He only threatened it!”" You're going out on a limb here. I'm not even countering that example as it's rigged to prevent that. Instead, I'll point out these unsafe things don't happen in a vacuum: there's something in the language that sets the risk in motion and then there's something else that determines what happens. The compile-time safety stops it from being set in motion. The run-time safety makes things set in motion meaningless as they'll just be exceptions or alerts for admins. Back to your analogy, it would be more like a prison learning environment where people learned in cells with bulletproof glass while one shouted he was "gonna cut someone" for not sharing answers. He can try every unsafe thing he wants but the glass makes it meaningless. The prisoner that's being targeted can literally just pretend all that unsafety doesn't even exist with no effect. Ideally, we have prevention and detection. Reason for prevention is obvious. Reason for detection, even in a perfect language scheme, is because compiler or hardware errors (esp SEU's) will make something act badly eventually with runtime measures being last-ditch effort. If there going to be there, though, then might as well lean on them some more if there's no performance hit, eh? ;)
        catnaroek 11y ago

nickpsecurity 11y ago

The tags are more commonly a few types like scaler, array, pointer w/ bounds, and so on. It checks basic stuff rather than full heap safety. Too tired to remember if there's one on that. The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The basics that go the furthest cost little to nothing in many designs. Then, you can go from there in your language or compiler design.

catnaroek 11y ago
> The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous.
- nickpsecurity 11y ago
  "The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous." I think we have a different definition of unsafe. If you think it's potential to cause problems, then I agree it doesn't make it less unsafe. Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system. That's what I'm claiming. Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly.
  - catnaroek 11y ago
    > I think we have a different definition of unsafe. “Potentially without useful meaning”, e.g., indexing an array without knowing whether the the index is within bounds. > Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system. Your kid (your data) attends the same school as a bully (your program). One day, the bully threatens to punch your kid in the face (raises an exception). “But it's less wrong because he never punched your kid! He only threatened it!” > Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly. As long as the assembly code has the same meaning as the safe program from which it was generated, it's safe.
    - nickpsecurity 11y ago
      "Your kid (your data) attends the same school as a bully (your program). One day, the bully threatens to punch your kid in the face (raises an exception). “But it's less wrong because he never punched your kid! He only threatened it!”" You're going out on a limb here. I'm not even countering that example as it's rigged to prevent that. Instead, I'll point out these unsafe things don't happen in a vacuum: there's something in the language that sets the risk in motion and then there's something else that determines what happens. The compile-time safety stops it from being set in motion. The run-time safety makes things set in motion meaningless as they'll just be exceptions or alerts for admins. Back to your analogy, it would be more like a prison learning environment where people learned in cells with bulletproof glass while one shouted he was "gonna cut someone" for not sharing answers. He can try every unsafe thing he wants but the glass makes it meaningless. The prisoner that's being targeted can literally just pretend all that unsafety doesn't even exist with no effect. Ideally, we have prevention and detection. Reason for prevention is obvious. Reason for detection, even in a perfect language scheme, is because compiler or hardware errors (esp SEU's) will make something act badly eventually with runtime measures being last-ditch effort. If there going to be there, though, then might as well lean on them some more if there's no performance hit, eh? ;)
      - catnaroek 11y ago