sivadeilra wrote: > Can you provide a more technical insight about how is this gonna be used? > What are the equivalent MSVC flags? Why is it that users (programmers) need > to select specific functions to hotpatch?
This PR is intended to allow LLVM-generated code to work with Windows hot-patching, also known as "Windows secure hot-patching". The "secure" part is relevant because the hot-patches generated by Windows meet Microsoft's requirements for binary signing and attestation. We use hot-patching for the Windows kernel, kernel-mode components (file systems, networking), device drivers, user-mode system services, user-mode applications, etc. The workflow that Microsoft uses relies on more information and behaviors than are currently publicly documented by the MSVC `/hotpatch` flag. There are two relevant behaviors in this PR: 1) the generation of the `S_HOTPATCHFUNC` symbol and the "double-indirection" when access global variables. The `S_HOTPATCHFUNC` symbol is produced by a compiler, then merged by the linker into the final PDBs. These PDBs are used by our hot-patching tools to locate symbols that were hot-patched. Our analysis tools look at the set of patched and not-patched functions and generate the patch description (also called "hot-patch metadata"). The patched code and the hot-patch metadata are then signed, in such a way that the Windows OS can verify the integrity of the hot-patch. The Windows kernel understands hot-patching and knows how to hot-patch images without triggering security violations. (After all, dynamically modifying kernel code is ordinarily considered hostile.) The "double-indirection" when access global variables allows hot-patched functions to access the instance of global variables in the original base image (which is actively executing), instead of accessing the second copy of the global variable that is in the hot-patch image. For const data, this is unimportant, but this is very important for mutable global data. This works by generating a `_ref_FOO` pointer variable for every `FOO` global variable. The hot-patch infrastructure in Windows knows about these `_ref_` variables and it initializes them to point to the correct variable instance. We are well aware of the limitations of hot-patching that this implies. Hot-patching is intended to be an optimization that can be applied in many circumstances, not a solution to every problem. Our tools inspect generated machine code and report errors when these requirements cannot be met. For example, hot-patching code that directly accesses TLS variables is out-of-scope. Hot-patching function statics is also currently out-of-scope, but with some work could be made to work. Our hot-patching tools and workflow allow us to generate hot-patches for the vast majority of CVEs that we fix, and this is the main focus for Windows hot-patching support. Windows hot-patching is not intended to be a replacement for Edit-and-Continue or to serve as a tool for interactive development. https://github.com/llvm/llvm-project/pull/138972 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
