On Wed Aug 20 19:57:20 2025 +0000, Alexandre Julliard wrote:
> DYNAMICBASE by itself is not meaningful for .exe.so binaries, they are
> mapped by the Unix loader anyway, which provides its own ASLR.
From my understanding, `winebuild` influences the PE section of this binary, which IS meaningful. This is reinforced by the fact that our plugins stop crashing when it's disabled.
The `HIGHENTROPYVA` should have no effect if `DYNAMICBASE` is off, so I can see a "not meaningful" there (but only on mutual exclusion), but I wanted to keep the PR as simple as possible.
I understand that Unix has [its own ASLR that's on by default](https://askubuntu.com/questions/318315), but to deny the meaningfulness of this flag seems -- respectively -- incorrect. This regression was introduced with 518e394794160818ffe6826c874ff2f550c95bbb and can be reverted just the same. I'm only asking to give `winegcc` (or more specifically `winebuild`) devs the ability to control it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113323
On Wed Aug 20 19:41:56 2025 +0000, Tres Finocchiaro wrote:
> `HIGHENTROPYVA:NO` allows `DYNAMICBASE` to remain active for both 32-bit
> and 64-bit executables while only disabling the 64-bit `HIGHENTROPYVA`
> features. Since `DYNAMICBASE` is widely preferred for security
> purposes, this provides just-enough granularity to close
> [#58480](https://bugs.winehq.org/show_bug.cgi?id=58480), and matches
> more closely to that of cygwin and MSVC compilers. Note that this
> `HIGHENTROPYVA:NO` solution is new information since creating that bug report.
> On the other hand, if it's winehq's stance that these flags should be
> toggled together, I'd happily change this back. I was fearful that
> handling them together may not be succinct enough, but I'm happy to oblige.
DYNAMICBASE by itself is not meaningful for .exe.so binaries, they are mapped by the Unix loader anyway, which provides its own ASLR.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113321
On Wed Aug 20 18:17:23 2025 +0000, Alexandre Julliard wrote:
> That second flag doesn't seem necessary.
`HIGHENTROPYVA:NO` allows `DYNAMICBASE` to remain active for both 32-bit and 64-bit executables while only disabling the 64-bit `HIGHENTROPYVA` features. Since `DYNAMICBASE` is widely preferred for security purposes, this provides just-enough granularity to close [#58480](https://bugs.winehq.org/show_bug.cgi?id=58480), and matches more closely to that of cygwin and MSVC compilers. Note that this `HIGHENTROPYVA:NO` solution is new information since creating that bug report.
On the other hand, if it's winehq's stance that these flags should be toggled together, I'd happily change this back. I was fearful that handling them together may not be succinct enough, but I'm happy to oblige.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113319
The `Allocate` method has two variants:
* Allocate(size_t): Performs a normal allocation, but throws a COMException on OOM.
* Allocate(ptrdiff_t offset, size_t size): Allocates a block of size `size`, and initializes a control block for an `IWeakReference` at `offset`. The weak reference resolves to the allocated object, which can finally be freed by calling `ControlBlock::ReleaseTarget`.
The IWeakReference implementation seems to be rather odd, which I have tried to demonstrate (and test) in the unit tests:
* `ReleaseTarget` only frees the object if the strong ref count is _below_ 0.
* `IWeakReference::Resolve` will _not_ set the output pointer to `NULL` if the weak reference is no longer alive.
This MR implements these functions sans exception support.
--
v2: vccorlib140: Implement Platform::Details::{Allocate(ptrdiff_t, size_t), ControlBlock::ReleaseTarget}.
vccorlib140: Add stub for Platform::Details::{Allocate(ptrdiff_t, size_t), ControlBlock::ReleaseTarget}.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8774