Re: How to use AddressSanitizer with Wine?

Yuxuan Shui <[email protected]> Wed, 7 May 2025 19:29:36 +0100
Newsgroups gmane.comp.emulators.wine.devel
Message-ID <CAGqt0zw556dOq6XmkhQVVywQb3bRTw+doJBorOMJhjJovS1NzQ@mail.gmail.com>
Hi,

On Tue, May 6, 2025 at 1:31 PM Bernhard Übelacker <[email protected]> wrote:
>
> Am 28.04.25 um 11:55 schrieb Yuxuan Shui:
> > Hi,
> >
> > I heard you were talking about ASan :)
> >
> > Just want to say that I happen to be working on ASan as well. Bernhard did
> > amazing work getting llvm's ASan runtime to work with Wine, however I am doing
> > a different approach. I want to be able to intrument the entirity of Wine, not
> > just PE. This has some challenges, created by e.g. the PE/Unix split, WoW64,
> > etc. I don't think any ASan runtimes can handle this yet, so I am working on
> > a special runtime for Wine. This is a lot of work, but on the flip side, this
> > should make running Wine under ASan much smoother, and rid us of the dependency
> > on compiler-rt.
> >
> > Ask me anything if this sounds interesting. Hopefully this idea doesn't sound
> > completely crazy to you ^^;
> >
> > Best,
> > Yuxuan
>
>
> Hello Yuxuan,
> this sounds interesting :-)

Thanks! BTW, I just got heap poisoning to work with wine's heap
allocator (though I
am still not sure if that's the best way to do it), and with that I
was able to replicate
some of your findings! It's such a relief to know I can indeed create a working,
independent ASan runtime.

>
> I wondered if it would be possible to use PE and unix side with ASan enabled,
> and guessed this might need some changes in synchronising both to access
> a single Shadow memory, but never tried something into this direction.

Yes, but more importantly, I wanted to cover as much of wine as
possible. This includes
some of the dlls I think you had to exempt from ASan, such as
ntdll.dll itself. Since ntdll
is the first dll to ever load, and in fact the code to load dlls is
part of ntdll, there is no
choice but to link an ASan runtime into ntdll, otherwise we can't
initialize the ASan
runtime early enough for ntdll to use. The biggest hurdle of doing
that would be the fact
that the existing libasan is written in C++, so I doubt we can ship
its source with wine.

Plus, writing an ASan runtime dedicated to wine also gives me more
control and allows
me to adapt to wine's needs. (e.g. I had to adjust shadow offset for
WoW64 mode since
that has mixed 32-bit and 64-bit code).

Oh, and I want to try and see if I can get LeakSan to work as well.
ASan on Windows
doesn't have that because they are missing `ptrace`. wine doesn't have
this limitation :)

>
> Kind regards,
> Bernhard

-- 

Regards
Yuxuan Shui