3 ms·

The method of filling spare bits with random values to guard against stale object access seems like it would probably work well in practice, but is there a way

The method of filling spare bits with random values to guard against stale object access seems like it would probably work well in practice, but is there a way to make it 100% air-tight and guarantee that stale object access will always be prevented? Otherwise it seems like that could end up as the basis of a security vulnerability in a program that uses this pattern.

backpropaganda 8y ago
It's only a security vulnerability if there is a bug already present in the code. This mechanism is not introducing the vulnerability. In fact, it's helping find out the bug during development. At release runtime, the spare bits should always match.
- rcthompson 8y ago
  I mean that if an object is deleted and its space in the array is reused for a new object, there's a small but non-zero chance that the spare bits will be identical, in which case the code would gain access to the new object when it is not supposed to. Or am I misunderstanding how the handle concept works?
  - backpropaganda 8y ago
    Yeah, I think you are misunderstanding something here. Yes, there is a non-zero chance that spare bits will be identical. But that's only relevant, if you have a bug in your code wherein you are trying to use a destroyed handle. If you are never using a destroyed handle, then the spare bits being identical is completely okay. Another way to think of this is that the spare bits are optional. The interface is good even if there were no spare bits. The spare bits only add an additional probabilistic security check.
    - naasking 8y ago
      The fact that it's probabilistic is what makes it unreliable as a real security check. That's how I understood the original poster's concern. It might also lend a false sense of security, like most other solutions that don't actually solve the full problem.
tom_ 8y ago
If you don't mind the handle being rather large, make the sequence number 64 bits, and store it alongside the index. 2^64 nanoseconds in years = 585... computers just aren't fast enough to wrap it around in any reasonable time frame. Depending on how many index bits you want, you might be good with only 64 bits in total. 2^56 ns in years = 2.3; 2^52 ns in days = 52; 2^48 ns in days = 3.3; and so on. All of these figures are worst case scenarios, anyway. Your program probably simply can't actually be made to allocate objects at that rate.
rocqua 8y ago
Use a lot of bits, increment upon re-use of the slot, and throw when the pattern reaches its maximum. Alternatively, give each item a unique handle (again counting up) and implement some sort of lookup table to convert those handles into actual indexes.

backpropaganda 8y ago

It's only a security vulnerability if there is a bug already present in the code. This mechanism is not introducing the vulnerability. In fact, it's helping find out the bug during development. At release runtime, the spare bits should always match.

rcthompson 8y ago
I mean that if an object is deleted and its space in the array is reused for a new object, there's a small but non-zero chance that the spare bits will be identical, in which case the code would gain access to the new object when it is not supposed to. Or am I misunderstanding how the handle concept works?
- backpropaganda 8y ago
  Yeah, I think you are misunderstanding something here. Yes, there is a non-zero chance that spare bits will be identical. But that's only relevant, if you have a bug in your code wherein you are trying to use a destroyed handle. If you are never using a destroyed handle, then the spare bits being identical is completely okay. Another way to think of this is that the spare bits are optional. The interface is good even if there were no spare bits. The spare bits only add an additional probabilistic security check.
  - naasking 8y ago
    The fact that it's probabilistic is what makes it unreliable as a real security check. That's how I understood the original poster's concern. It might also lend a false sense of security, like most other solutions that don't actually solve the full problem.

tom_ 8y ago

If you don't mind the handle being rather large, make the sequence number 64 bits, and store it alongside the index. 2^64 nanoseconds in years = 585... computers just aren't fast enough to wrap it around in any reasonable time frame. Depending on how many index bits you want, you might be good with only 64 bits in total. 2^56 ns in years = 2.3; 2^52 ns in days = 52; 2^48 ns in days = 3.3; and so on. All of these figures are worst case scenarios, anyway. Your program probably simply can't actually be made to allocate objects at that rate.

rocqua 8y ago

Use a lot of bits, increment upon re-use of the slot, and throw when the pattern reaches its maximum. Alternatively, give each item a unique handle (again counting up) and implement some sort of lookup table to convert those handles into actual indexes.