Comment by anonymars

Comment by anonymars 15 hours ago

4 replies

View on Hacker News

Briefly: it can (see e.g https://devblogs.microsoft.com/oldnewthing/20130102-00/?p=56...)

Note that just replacing files on disk is not sufficient because all the running software would still have the old version.

In the first place it means the security issue could still be present in currently running software, in the second place exciting things can happen when two (or more?!) different versions try to talk to each other. Oh, and who's to say the whole file was fully loaded into memory (or wasn't partially paged out) - imagine the fun that would happen if you later page in data from a different version of the binary!

So you need to hot patch the running binaries. I don't really remember why it's not done in practice even though it's technically possible, I seem to remember the conclusion was that clustering (in whatever form) was the solution for high availability, rather than trying to keep a single machine running.

toast0 13 hours ago

> So you need to hot patch the running binaries. I don't really remember why it's not done in practice even though it's technically possible, I seem to remember the conclusion was that clustering (in whatever form) was the solution for high availability, rather than trying to keep a single machine running.

Most systems are technically capable of hot patching (if your exe file is mmaped, and you change the backing file, Bob's your uncle, unless your OS is no fun; which is why unix install pattern is unlink and replace rather than in-place updares). But most executables are not built to be hot patched, especially not without coordination.

Hot patching lets you make changes to your live environment with tremendous speed, but it also has risk of changing your live environment to an offline environment with tremendous speed. I'm a proponent of hot patching, and would love to be able to hot load all the things, but it has requirements and tradeoffs and most software isn't built for it, and that's probably the right decision for most things.

Reply View 1 reply
  • anonymars 13 hours ago

    Yep. In fact rename/replace is conceptually the same as unlink/replace, but another potential issue is in-process dll hell. If a patch replaces multiple libraries, and they're not all loaded into a process yet, even if each is atomic, you might load version 1 of the first library but version 2 of the second

    Reply View 0 replies
Brian_K_White 11 hours ago

There is no such partial or mixed exe problem from paging.

It doesn't matter if it was paged out, virtual memory is still just memory.

Paging out & restoring some memory doesn't know or care where the contents originally came from. It doesn't have an optimization that goes "Oh this chunk of memory is an executable file. I can skip writing this out to the swap file, and later when I need to restore it I can just read the original file instead of swap."

For files that a program opens, an open handle is an open handle. The entire file is available in whatever state it was at the time the handle was opened, modulo whatever changes this specific handle has made.

If a program closes and re-opens handles, then it always knew that the entire world could have changed between those 2 opens. Same if it opens non-exclusive. If it opens without exclusive or closes & reopens, then it's ok for the data to change between each access.

There are problems during updates, but they are much higher level and safer than that. Open file handles are open file handles, and currenly loaded exes are consistent and sane until they close. All the problems are in the higher level domains of processes interacting with each other.

Reply View 1 reply