PE: Add parser for dynamic relocation (DVRT)

[kkent030315]

This PR adds support for dynamic value relocation table (DVRT) for PE32/64. DVRT info is provided in load config directory. Generally speaking, DVRT is a feature to mitigate Spectre variant 2 (branch target injection), for example, by dynamically relocating indirect jumps or calls to ”retpoline” pages. DVRT contains where such indirect call targets and jumps are located within the executable.

There are 8 types of dynamic relocation as of now, which this PR adds 5 of them. DVRT has 2 versions as of now (1 and 2) and this PR currently only supports 1.

• [x] DVRT V1
  • [ ] IMAGE_DYNAMIC_RELOCATION_GUARD_RF_PROLOGUE
  • [ ] IMAGE_DYNAMIC_RELOCATION_GUARD_RF_EPILOGUE
  • [x] IMAGE_DYNAMIC_RELOCATION_GUARD_IMPORT_CONTROL_TRANSFER
  • [x] IMAGE_DYNAMIC_RELOCATION_GUARD_INDIR_CONTROL_TRANSFER
  • [x] IMAGE_DYNAMIC_RELOCATION_GUARD_SWITCHTABLE_BRANCH
  • [x] IMAGE_DYNAMIC_RELOCATION_ARM64X
  • [ ] IMAGE_DYNAMIC_RELOCATION_FUNCTION_OVERRIDE
  • [x] IMAGE_DYNAMIC_RELOCATION_ARM64_KERNEL_IMPORT_CALL_TRANSFER
• [ ] DVRT V2
  • [ ] IMAGE_DYNAMIC_RELOCATION_GUARD_RF_PROLOGUE
  • [ ] IMAGE_DYNAMIC_RELOCATION_GUARD_RF_EPILOGUE
  • [ ] IMAGE_DYNAMIC_RELOCATION_GUARD_IMPORT_CONTROL_TRANSFER
  • [ ] IMAGE_DYNAMIC_RELOCATION_GUARD_INDIR_CONTROL_TRANSFER
  • [ ] IMAGE_DYNAMIC_RELOCATION_GUARD_SWITCHTABLE_BRANCH
  • [ ] IMAGE_DYNAMIC_RELOCATION_ARM64X
  • [ ] IMAGE_DYNAMIC_RELOCATION_FUNCTION_OVERRIDE
  • [ ] IMAGE_DYNAMIC_RELOCATION_ARM64_KERNEL_IMPORT_CALL_TRANSFER

DVRT V2 and other relocation types are probably going to be implemented in follow-up PRs.

Reference:

• https://denuvosoftwaresolutions.github.io/DVRT/dvrt.html (Only DVRT v1; not entirely covered)

[m4b]

this probably needs a rebase/my comments still need some clarification. we can focus on the other outstanding PR for delay import parser in the meantime though :)

[kkent030315]

This looks pretty good, with some nits; this is a large amount of code though! We should also begin to be careful putting Debug on all structs, as this can lead to an increase in compile times, fwiw. Unavoidable if something higher up requires it.

I'm curious, are portions of this ai generated? If yes, that's fine, I'm just wondering how we can better test that some of the e.g., bit masking logic and other details that I wouldn't have the semantic background to know is correct, is correct.

Ok, I will try to strip Debug derives as possible as it can. It helps me easily debug while writing code and perhaps we should impl Display instead..?

Not really generated by AI. AI sucks for this kind of work and is very trivial to mistake. I think I'd use it for doc comments and some trivial tests. It would definitely do better when it comes to generating tests for bit masking helpers.