Hacker News Reader

Comment by wyldfire | Hacker News Reader

What's the use case for this feature? Altering a thread's (or set of threads') work dynamically because synchronizing with those threads is too expensive? Or in an actual case would "goodbye()" contain code which was only generated as late as runtime?

It's neat, but I'm wondering why simpler things like updating a function pointer wouldn't be sufficient.

View on HN

Usually it's done when redesigning/recompiling the target function is not possible. Game modding, restartless updates, instrumentation, etc.

But that would only be possible from the same process space, right? So only applicable for plugins etc.?

What I'd like to see is hotpatching the function for another process, but I guess that's very hard to do with ASLR. Probably doable with some tricks, though.

Edit: Come to think of it, gdb is able to attach to a running process w/o debug symbols and find function addresses. So in other words, I just need to dig into and grok the gdb source.

The program being modified doesn't need some feature for loading your code as a plugin. You can instead use https://en.wikipedia.org/wiki/DLL_injection

If you are able to recompile the program, you can disable ASLR. For example on iOS it just requires a change to the MACH-O header of the binary. [0]

But I doubt you could disable ASLR of a running process, for somewhat obvious reasons...

[0] https://github.com/peterfillmore/removePIE

You can similarly disable ASLR via the header in Windows, though there are ways to override that.

ASLR shouldn't be a big problem though. Only the base address of code in each file (executable or library) is changed, and you can easily find it. Functions within one file are not shuffled around. ASLR only exists to stop you from hard-coding function addresses, to make exploits harder.

If you want restartless updates, then you plan for it and modularize the software with dynamically loadable modules (think shared library "plugins" or kernel modules).

You're talking about when you own the source and therefore can redesign/recompile it. I began my comment explicitly ruling those cases out.

Let's say you're Red Hat, and want to release a super critical security fix for some package, but you absolutely cannot restart the affected process. This technique allows you to write some code that redirects functions to fixed versions, patching the process while it runs.

If you don't control the code and can't recompile it, you won't be able to add the ms_hook_prologue function property

If you don't control the code and are modifying it to do an in-service upgrade of a running binary, then this is a special situation: you're shooting a 2016 re-make of MacGyver targeted at a geek/programmer audience.

If you're Red Hat and you do have the source, but the service cannot be stopped, and yet it must be upgraded, yet you didn't plan this into the software (and yet you didn't write in it in Lisp which could save your ass here) then you're plain stupid. If you're stupid, you're not going to pull off this highly technical, intricate hack, that is looming with pitfalls.

I mentioned this in another comment, but you don't need the ms_hook_prologue attribute, it's just helpful.

True, you don't usually need the prologue to hook a function, but we're talking about hooking functions that might be called by another thread at the same time. If you just modify the instructions while another thread is running the code, you might crash and burn. The prologue helps by ensuring the first 8 bytes of a function are just a large NOP.

Except the technique presented requires recompiling the target function, doesn't it? (To add all those GCC attributes, and to add the `lea` instruction.)

The specific technique shown here requires it, but you can also do it generically by overwriting the first 8 bytes of the function and then restoring it later if you want to undo the hook.

If you change the function pointer, then you have to be aware of the calling convention used by the compiler and make sure you replicate it. Another can of worms. https://en.wikipedia.org/wiki/X86_calling_conventions

as for the synchronization use case, even though it's probably way more expensive to invalidate another thread's instruction cache than any other usual sync. method, it can be useful if there is a huge number of synchronization point but it happens very rarely and you don't want to bloat the code with explicit checks everywhere.

An example of that is garbage collection safepoints, although in that case you also need to be able to patch a function in the middle (any potentially unbounded control flow loop)

Reply on news.ycombinator.com