4 ms·

The fact that this is a problem is probably a sign that every OS should do this from the start so that apps won't be written that...rely on this behavior.

dividuum 4y ago
It’s not really an OS problem: it’s the userland allocator that needs to implement this. So on Linux that would mostly be a glibc change to how malloc/free is implemented. The OS itself doesn’t know whether or not a processes memory page is logically „in use“. It only knows that once the process returns it (using for example munmap). But once you do that, any access crashes the process already.
- noobermin 4y ago
  I hope you won't call me stallman but in my brain libc should be considered part of the OS, but yes, it would be clearer if I said "libc's should do it."
tinus_hn 4y ago
The article does not actually claim this is a problem, it states the author thinks it will probably be a problem. I doubt this actually will be a problem for 99% of all apps, the ‘but what about this essential software from 50 years ago’ problem does not exist on Apple platforms because they routinely deprecate and then drop obsolete software without mercy. The only real problem I can imagine occurring is that this change uncovers dangerous security vulnerabilities that are a crash (so a denial of service) on those platforms but an exploit on others. But that’s a problem for those other platforms to deal with.
spacecadet_ 4y ago
Apps aren't being written _on purpose_ to rely on the allocator doing nothing with freed memory because that's not in its interface, and this change doesn't actually do anything to stop apps from reading freed memory. There is no behavior that a program could legally rely on when reading freed memory. The assumption behind malloc/free is that freed allocations aren't used by the program anymore, so correct programs don't rely on reading freed memory at all and the allocator implementation is then free to do anything at all with the freed memory, it just turns out that the simplest behavior on the allocator side is to do nothing at all and just leave the freed memory as-is. The only thing this does when speaking of programs reading freed memory is that it breaks existing incorrect programs that just happened to work because of an implementation detail of the allocator, and then later someone will write another incorrect program that just happens to work because the allocator now zeroes out freed memory. To actually stop the problem of programs reading freed memory, the OS side would have to enforce the use of memory-safe languages which by design cannot access unused memory.
- noobermin 4y ago
  To be very explicit, the "...rely" is me being facetious, I'm not really implying anyone actually relies on use after free! More like they lucked out on not catching it and shipped it anyway, hence the "rely" bit.
- ncmncm 4y ago
  Writing random values to freed memory would mostly work, at some cost to performance. The memory could get allocated again before it is re-used, and whatever is put in it might be less trappy than a random value. And, of course, a random value might not trap. Better is not to do things that result in referring to dead memory: easy in modern C++, apparently difficult in C.

dividuum 4y ago

It’s not really an OS problem: it’s the userland allocator that needs to implement this. So on Linux that would mostly be a glibc change to how malloc/free is implemented. The OS itself doesn’t know whether or not a processes memory page is logically „in use“. It only knows that once the process returns it (using for example munmap). But once you do that, any access crashes the process already.

noobermin 4y ago
I hope you won't call me stallman but in my brain libc should be considered part of the OS, but yes, it would be clearer if I said "libc's should do it."

tinus_hn 4y ago

The article does not actually claim this is a problem, it states the author thinks it will probably be a problem. I doubt this actually will be a problem for 99% of all apps, the ‘but what about this essential software from 50 years ago’ problem does not exist on Apple platforms because they routinely deprecate and then drop obsolete software without mercy. The only real problem I can imagine occurring is that this change uncovers dangerous security vulnerabilities that are a crash (so a denial of service) on those platforms but an exploit on others. But that’s a problem for those other platforms to deal with.

spacecadet_ 4y ago

Apps aren't being written _on purpose_ to rely on the allocator doing nothing with freed memory because that's not in its interface, and this change doesn't actually do anything to stop apps from reading freed memory. There is no behavior that a program could legally rely on when reading freed memory. The assumption behind malloc/free is that freed allocations aren't used by the program anymore, so correct programs don't rely on reading freed memory at all and the allocator implementation is then free to do anything at all with the freed memory, it just turns out that the simplest behavior on the allocator side is to do nothing at all and just leave the freed memory as-is. The only thing this does when speaking of programs reading freed memory is that it breaks existing incorrect programs that just happened to work because of an implementation detail of the allocator, and then later someone will write another incorrect program that just happens to work because the allocator now zeroes out freed memory. To actually stop the problem of programs reading freed memory, the OS side would have to enforce the use of memory-safe languages which by design cannot access unused memory.

noobermin 4y ago
To be very explicit, the "...rely" is me being facetious, I'm not really implying anyone actually relies on use after free! More like they lucked out on not catching it and shipped it anyway, hence the "rely" bit.
ncmncm 4y ago
Writing random values to freed memory would mostly work, at some cost to performance. The memory could get allocated again before it is re-used, and whatever is put in it might be less trappy than a random value. And, of course, a random value might not trap. Better is not to do things that result in referring to dead memory: easy in modern C++, apparently difficult in C.