[LLD] [COFF] PE delayload compatibility with IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION

[jeremyd2019]

In https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-load-configuration-structure-image-only, the IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION flag is described as "Delayload import table in its own .didat section (with nothing else in it) that can be freely reprotected."

I am preparing a patch to binutils to put the delay IAT in its own (read/write) .didat output section. I would then like to prepare a pull request to LLD to do the same. However, I see that LLD is currently using .didat input section for the delay load directory table instead. Is this something that's done for compatibility with MS link.exe and cannot be changed, or would it be acceptable to move that into .rdata to put only the delay IAT in .didat ?

@mstorsjo @lhmouse

[jeremyd2019]

also, is there any precedent for naming a linker command argument to set the IMAGE_GUARD_PROTECT_DELAYLOAD_IAT and/or IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION guard flag? binutils does not yet have the CFG symbols so there's nothing there, and I didn't notice any option in MS link.exe documentation

[lhmouse]

I don't know for a precise answer. You may use objdump -s -j '.didata' to dump the contents of an executable that is created by MSVC.

[jeremyd2019]

At least LLD merges .didat into .rdata in the final executable, so there'd be no .didat in the executable. I don't have msvc installed, and I don't know if I can get godbolt to show me dll/exe sections rather than disassembly.

[mstorsjo]

I would then like to prepare a pull request to LLD to do the same. However, I see that LLD is currently using .didat input section for the delay load directory table instead. Is this something that's done for compatibility with MS link.exe and cannot be changed, or would it be acceptable to move that into .rdata to put only the delay IAT in .didat ?

I haven't studied that closely recently, but I would say that we should try to mimic what MS link.exe does here, unless we have a good reason to diverge. And so far I would think that the implementation has tried to mimic that - but if there are cases that differ, we should probably first try to fix that.

Also CC @cjacek.

At least LLD merges .didat into .rdata in the final executable, so there'd be no .didat in the executable. I don't have msvc installed, and I don't know if I can get godbolt to show me dll/exe sections rather than disassembly.

FWIW, with https://github.com/mstorsjo/msvc-wine its quite quick and easy to install MSVC on Linux, if you happen to be running that. It's quite useful for quick testing/comparisons/investigating details like these.

also, is there any precedent for naming a linker command argument to set the IMAGE_GUARD_PROTECT_DELAYLOAD_IAT and/or IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION guard flag? binutils does not yet have the CFG symbols so there's nothing there, and I didn't notice any option in MS link.exe documentation

Hmm, no idea actually. It sounds odd if MS have defined such a flag but not actually expose a way to enable it in MS link.exe? For the ld.lld interface, there's certainly no precedent, so we should probably just come up with a name consistent with the others, and try to add it with the same name on the binutils side soon afterwards (if possible), so that nobody else ends up implementing it there with a different name.

[jeremyd2019]

yeah, I want to contribute the patches to binutils, but I want to make sure the approach I'm using there isn't incompatible with either what MS link.exe or LLD does.

[jeremyd2019]

To clarify, currently LLD puts the read-only-data parts of the delayimp stuff (that is, dirs, names, hintNames, dllNames) in a .didat section, which then gets merged into .rdata, while addresses gets put in the .data section (along with moduleHandles). What I'm proposing is to put the stuff that ends up in .rdata directly into .rdata and then put addresses only into a read/write .didat section that does not get merged into some other section. It appears that moduleHandles should continue to go into .data (the PE format document explicity says "The handle of the DLL to be delay-loaded is in the data section of the image").

If the IMAGE_GUARD_PROTECT_DELAYLOAD_IAT flag is set (and the OS supports it), the loader will then change the protection of the pages that the addresses wind up in to readonly, and then temporarily switch it back to read/write when updating it in ResolveDelayLoadedAPI. Setting this flag in an LLD-linked binary now is a good way to crash, because it winds up making part of the .data section read-only. I'm not sure exactly what difference the IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION flag has on Windows' behavior, it seems pretty necessary for correct functioning of the PROTECT_DELAYLOAD_IAT mechanism to me.

/cc @llvm/issue-subscribers-lld-coff

[mstorsjo]

What I'm proposing is to put the stuff that ends up in .rdata directly into .rdata and then put addresses only into a read/write .didat section that does not get merged into some other section. It appears that moduleHandles should continue to go into .data (the PE format document explicity says "The handle of the DLL to be delay-loaded is in the data section of the image").

Is this what MS link.exe does?

[jeremyd2019]

What I'm proposing is to put the stuff that ends up in .rdata directly into .rdata and then put addresses only into a read/write .didat section that does not get merged into some other section. It appears that moduleHandles should continue to go into .data (the PE format document explicity says "The handle of the DLL to be delay-loaded is in the data section of the image").

Is this what MS link.exe does?

I was hoping somebody here would tell me 😜 Regardless, based on the docs and behavior I observed, I think this is the correct thing to do for compatibility with the protected delayload feature.

I guess I'll have to google cl and link command lines and do a little test in GHA and see what MS does...

[lhmouse]

Don't you have a Windows machine?

It would be a weird situation for anyone who develops Windows apps without a Windows installation, no matter how hard they try to deny that.

Other than Windows itself, the Microsoft compiler has actually been free of charge, installable as part of their SDK, for more than two decades.

[jeremyd2019]

yes, but I don't have it installed on any of my machines at the moment, and I don't really want to if I can help it.

[jeremyd2019]

test source:

#include <assert.h>
#include <stdio.h>
#include <winsock2.h>
#include <windows.h>

__attribute__((__used__))
const IMAGE_LOAD_CONFIG_DIRECTORY _load_config_used = {
  .Size = sizeof(_load_config_used),
  .GuardFlags = 0x3000, /*IMAGE_GUARD_PROTECT_DELAYLOAD_IAT|IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION*/
};

int global_var = 42;

int main(void) {
  unsigned short ret;
  setvbuf(stdout, NULL, _IONBF, 0);
  printf("MAIN: starting\n");
  printf("MAIN: incremented global var = %d\n", ++global_var);
  printf("MAIN: about to call htons\n");
  ret = htons(0x1234);
  printf("MAIN: htons returned %hx\n", ret);
  printf("MAIN: incremented global var = %d\n", ++global_var);
  printf("MAIN: OK\n");
  return 0;
}

build with

clang -fuse-ld=lld -o main.exe main.c -lws2_32 -Wl,-delayload,WS2_32.dll -ldloadhelper

main.exe crashes when the loader tries to set up TLS stuff, which is now in a read-only page apparently.

[jeremyd2019]

Binutils patches sent https://inbox.sourceware.org/binutils/e2ac90bc-0fba-ccd0-c7a1-63c37fa7597c@huh/T/#u