libera/#sicl - IRC Chatlog
Search
2:19:45
moon-child
obviously, it is a safety problem to be able to turn an integer into a pointer. Is it a problem to be able to go the other way?
2:21:34
moon-child
I suppose it could be used to aid in exploiting other vulnerabilities. But while I can not see any problem with it per se, I also can not think of any reason why it would be useful to interpret the address of an object as an integer, unless debugging a gc
2:23:07
moon-child
many implementations will print an unreadable object using its address by default. But this seems suspect to me. An object could move to a different address; an object could be reclaimed, and another could be given the same address; addresses are not very distinctive, and a human may not immediately be able to tell the difference between two similar-looking addresses
2:23:39
moon-child
a display of slots, while somewhat unprincipled, would be no _less_ unprincipled due to the above problems, and probably more useful
2:25:48
hayley
I heard Java prints the identity hash code by default, which is stable regardless of GC.
3:35:58
Bike
displaying the pointer is pretty convenient practically speaking, and not as verbose as dumping slots
4:05:40
Bike
might be nice if you could kind of reverse hash it into something more human readable arbitrary text
10:44:12
pjb
moon-child: it is a security-by-obscurity breach to convert pointers to integers, but the biggest problem is that if you have a moving garbage collector, it less than useful. Better print out object IDs instead of their address.
13:00:39
jcowan
one idea is to keep object ids only for objects that have been moved, on the assumption that these are few: when you move an object, check if it has an ID, and if not, add one.
13:04:44
moon-child
how do you generate object ids? Sicl hash is a random number; those could collide. You could use an incrementing counter, with a different offset for each thread, but then it wouldn't work as a hash
13:05:08
moon-child
I guess you could use a cheap perfect hash like xxhash and invert it for printing?
13:52:19
jcowan
You can reduce the size of collisions to as small as you want. 128-bit UUIDs are generally considered to be strong enough: generate 1 billion per second for 100 years and your probability of collision rises to 50%, but really.