[PATCH v4 0/27] MR8026: Draft: RFC: Running wine with AddressSanitizer

[Yuxuan Shui (＠yshui)]

Please see: https://marc.info/?l=wine-devel&m=174715050805731 as well as the commit messages for more information.

--
  v4: ntdll: Report more info about heap problems detected by ASan.
      ntdll: Show (partial) stack trace in ASan reports.
      ntdll: Add heap quarantine for ASan.
      ntdll: Add asan poisoning and redzoning to heap allocator
      ntdll: Implement ASan fake stack.
      ntdll: Don't use address of local variables as the frame address.
      ntdll: During unwind, also check if frame is on fake stack.
      ntdll: Implement __asan_{un,}poison_memory_region.
      ntdll: Make sure to not write into poisoned memory in KeUserModeCallback.
      ntdll: Implement __asan_set_shadow_*.
      ntdll: Implement reporting of ASan errors.
      ntdll: Implement __asan_{memory,region}_is_poisoned.
      ntdll: Implement __asan_{un,}poison_stack_memory.
      ntdll: Unpoison stack in __asan_handle_no_return.
      ntdll: Add API for checking whether address is in fake stack frame.
      kernel32: Check for poison in LocalLock if ASan is enabled.
      kernel32: Fix ASan reports in IsBad*
      ntdll: Call __asan_handle_no_return in RtlRestoreContext.
      makedep: Support sanitizer flags.
      asan_dynamic_thunk: Add ASan dynamic thunk for DLLs.
      ntdll: Add stub ASan runtime.
      loader: Disable sanitization.
      configure: Check for sanitizer support.

This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8026

[Yuxuan Shui (＠yshui)]

On Thu May 15 12:41:50 2025 +0000, Yuxuan Shui wrote:
> i will push new, unorganized changes to
> [`wip/address-sanitizer`](https://gitlab.winehq.org/yshui/wine/-/tree/wip/address-sanitizer?ref_type=h...),
> and will only push cleaned up versions here, so i don't create too much noise.

updated based on suggestions from @iamahuman - now no new symbols are exported from ntdll and i was able to get rid of the pesky DLL initialization hook as well (see https://gitlab.winehq.org/wine/wine/-/commit/6616df42bcaf754ddeb40100f89bddb...). thanks!

[Paul Gofman (＠gofman)]

> the rest of the changes are:

well, there are changes to RtlRestoreContext (that is probably not exhaustive, we have more no return places like that?), KeUserModeCallback (while maybe __builtin_frame_address is not portable), loader / unwinding, kernelbase (probably similar should be in virtual_check_buffer_for_write and friends in ntdll unless it is already there), kernel32, and more. I also suspect this is not exhaustive list and more issues requiring workarounds for Asan will be discovered later.

I know catching this wide range of issues with just a buiid with special compiled flag is great. But if you have to build the whole thing around it (very specific thing, Wine is not an usual app working with memory on its own will and rules) we should be careful not to affect compatibility (maybe achieavable) and also consider maintenance burden of all that support throughout the system.

[Alexandre Julliard (＠julliard)]

On Thu May 15 19:50:54 2025 +0000, Paul Gofman wrote:
> > the rest of the changes are:
>
> well, there are changes to RtlRestoreContext (that is probably not
> exhaustive, we have more no return places like that?),
> KeUserModeCallback (while maybe __builtin_frame_address is not
> portable), loader / unwinding, kernelbase (probably similar should be in
> virtual_check_buffer_for_write and friends in ntdll unless it is already
> there), kernel32, and more. I also suspect this is not exhaustive list
> and more issues requiring workarounds for Asan will be discovered later.
> I know catching this wide range of issues with just a buiid with special
> compiled flag is great. But if you have to build the whole thing around
> it (very specific thing, Wine is not an usual app working with memory on
> its own will and rules) we should be careful not to affect compatibility
> (maybe achieavable) and also consider maintenance burden of all that
> support throughout the system.

I agree with Paul, getting the Windows runtime to work looks like a more promising solution. Sure, it would maybe test only 90% of the code, but that seems like a worthwhile trade-off for (presumably) much lower maintenance.

[Brendan Shanks (＠bshanks)]

Instead of `--enable-sanitize`, maybe the configure flag could be `--enable-sanitizer=<option>` with `address` being the only option supported at first. This makes it straightforward to add support for other sanitizers later.