LoadAllImportsForDll before patching a function using IATPatchFunction
If a delayloaded function is patched using IATPatchFunction and then later there are method calls to the same DLL, the delayloadhelper will fully realize the IAT for that DLL, overwriting the patch. This change forces all of the imports to get loaded before the patch is created. The primary scenario for this is the GDI patch for GetFontData done in InitializePDF(). This presents a problem, however, because this method is currently called during startup for every child process, thus negating the work done to make GDI delayloaded in the first place. As such, this change also makes two optimizations to prevent losing the delayload perf benefits: 1. For PDF (ppapi) processes, ensures InitializePDF's patches only run on Win7 and Win8. This is done because Win10 uses different font retrieval mechanisms because of win32k process mitigations. 2a. Ensures InitializePDF runs for ppapi processes. Since this code is only actually needed for PDF rendering, there's no reason to do it for every child process. The LoadAllImports + patching then becomes pay-for-play when a PDF is being viewed. 2b. Ensures InitializePDF runs for printing utility processes which use the GDI-based font information on all Windows versions. Bug: 988164 Change-Id: I4d3c560a7c022c09251773c2a0d1cb4585da2145 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1731175 Commit-Queue: Cliff Smolinsky <cliffsmo@microsoft.com> Reviewed-by:Lei Zhang <thestig@chromium.org> Reviewed-by:
Bruce Dawson <brucedawson@chromium.org> Reviewed-by:
Greg Thompson <grt@chromium.org> Cr-Commit-Position: refs/heads/master@{#686696}
Showing
Please register or sign in to comment