4 ms·

Since the CPU instructions are the same, instruction patching at startup or install time can be used. Just patch in the correct instructions for the respective

• saagarjha 3y ago
  This is generally a bad idea because it requires code modification, which has security implications. Most implementations will bring in multiple implementations and select the right one at startup (amortizing the indirect call into something like the GOT which already exists).
  • JonChesterfield 3y ago
    There are security hazards around writable + executable code. They don't apply to patching before execution (e.g. the install step) since nothing needs to be executed at that point. I don't think the security concerns apply during load time either - what does it matter if the text section is edited before it gets marked read-only&executable? It just means you're running a slightly different program, exactly as if it was edited during install. In the memcpy case, where the library call is probably in a dynamically linked library anyway, it's particularly trivial to bind to one of N implementations of memcpy at load time. That only patches code if library calls are usually implemented that way. Patching .text does tend to mess up using the same shared pages across multiple executables though which is a shame, and somewhat argues for install time specialisation.
    • saagarjha 3y ago
      On certain platforms, it would break code signatures if they are tied to the pages the code is on.
      • andrekandre 3y ago
        > On certain platforms, it would break code signatures macos?
        • saagarjha 3y ago
          Yeah, or iOS. Or other platforms that adopt a similar model