4 ms·

ARM actually kind of has that. The register file has an overflow flag that is not cleared on subsequent operations (sticky overflow). So instead of triggering a

ARM actually kind of has that. The register file has an overflow flag that is not cleared on subsequent operations (sticky overflow). So instead of triggering an exception, which is prohibitively expensive, you can do a series of calculations and check afterwards if an overflow happened in any of them. A bit like NaN for floating point. From what I understand the flag alone is still costly, so we will have to see if it survives.

spookie 3y ago
That's quite interesting and reasonable
andersa 3y ago
It doesn't matter if triggering the exception is expensive. At that point overflow has already occured, so your program state is now nonsense, and you might as well just let it crash unhandled. Much better outcome than reading memory at some mysterious offset. If just having the ability for an exception to occur during an instruction causes overhead, that would be a big problem though. Edit to add: We need to do the check on every operation. Just going through one iteration of the loop might have already corrupted some arbitrary memory, for example. Manually inserted checks on some flag bits don't scale to securing real programs.
- weinzierl 3y ago
  Think about it like that. If you allow an exception you essentially create many branches with all their negative consequences. With the sticky bit you combine them to one branch (that is still expensive[1]). [1] https://news.ycombinator.com/item?id=8766417 https://news.ycombinator.com/item?id=8766417
- Findecanor 3y ago
  > At that point overflow has already occured, so your program state is now nonsense, and you might as well just let it crash unhandled. The trick is to check and clear the flag before any instruction that would have a side-effect, that depends on the arithmetic result. IEEE 754-compliant floating point units have a similar behaviour with NaN that is a bit more versatile: an arithmetic instruction results in NaN if any operand is NaN, but an instruction with side-effect (compare, convert or store) will raise an exception if given a NaN.
deleted 3y ago
[deleted]

spookie 3y ago

That's quite interesting and reasonable

andersa 3y ago

It doesn't matter if triggering the exception is expensive. At that point overflow has already occured, so your program state is now nonsense, and you might as well just let it crash unhandled. Much better outcome than reading memory at some mysterious offset. If just having the ability for an exception to occur during an instruction causes overhead, that would be a big problem though. Edit to add: We need to do the check on every operation. Just going through one iteration of the loop might have already corrupted some arbitrary memory, for example. Manually inserted checks on some flag bits don't scale to securing real programs.

weinzierl 3y ago
Think about it like that. If you allow an exception you essentially create many branches with all their negative consequences. With the sticky bit you combine them to one branch (that is still expensive[1]). [1] https://news.ycombinator.com/item?id=8766417 https://news.ycombinator.com/item?id=8766417
Findecanor 3y ago
> At that point overflow has already occured, so your program state is now nonsense, and you might as well just let it crash unhandled. The trick is to check and clear the flag before any instruction that would have a side-effect, that depends on the arithmetic result. IEEE 754-compliant floating point units have a similar behaviour with NaN that is a bit more versatile: an arithmetic instruction results in NaN if any operand is NaN, but an instruction with side-effect (compare, convert or store) will raise an exception if given a NaN.

deleted 3y ago

[deleted]