Bugzilla

Here are some notes for the future.

[:jrmuizel] pointed out that [some other processes already have ACG with ASAN](https://searchfox.org/mozilla-central/source/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#1220). They are using `SetDelayedProcessMitigations` to achieve that, meaning that the mitigation will be applied after initialization (in particular, after ASAN initialization). Since the code to do this already exists, we could consider using `SetDelayedProcessMitigations` to enable ACG in ASAN builds here too, mostly for the sake of having consistent behavior between the two kinds of builds and not really for a security reason.

Regarding release builds however, if everything works with the non-delayed approach, I'd recommend keeping it non-delayed for them. The security impact is better with a non-delayed ACG. The problem I see with enabling the mitigation as delayed is that I think the legitimate code that runs before the mitigation is applied is allowed to allocate RWX memory that may survive for the rest of the life of the process. I don't think delayed ACG would catch this if it came to happen.

Here are some notes for the future.

[:jrmuizel] pointed out that [some other processes already have ACG with ASAN](https://searchfox.org/mozilla-central/source/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#1205). They are using `SetDelayedProcessMitigations` to achieve that, meaning that the mitigation will be applied after initialization (in particular, after ASAN initialization). Since the code to do this already exists, we could consider using `SetDelayedProcessMitigations` to enable ACG in ASAN builds here too, mostly for the sake of having consistent behavior between the two kinds of builds and not really for a security reason.

Regarding release builds however, if everything works with the non-delayed approach, I'd recommend keeping it non-delayed for them. The security impact is better with a non-delayed ACG. The problem I see with enabling the mitigation as delayed is that I think the legitimate code that runs before the mitigation is applied is allowed to allocate RWX memory that may survive for the rest of the life of the process. I don't think delayed ACG would catch this if it came to happen.

Here are some notes for the future.

[:jrmuizel] pointed out that [some other processes already have ACG with ASAN](https://searchfox.org/mozilla-central/source/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#1238). They are using `SetDelayedProcessMitigations` to achieve that, meaning that the mitigation will be applied after initialization (in particular, after ASAN initialization). Since the code to do this already exists, we could consider using `SetDelayedProcessMitigations` to enable ACG in ASAN builds here too, mostly for the sake of having consistent behavior between the two kinds of builds and not really for a security reason.

Regarding release builds however, if everything works with the non-delayed approach, I'd recommend keeping it non-delayed for them. The security impact is better with a non-delayed ACG. The problem I see with enabling the mitigation as delayed is that I think the legitimate code that runs before the mitigation is applied is allowed to allocate RWX memory that may survive for the rest of the life of the process. I don't think delayed ACG would catch this if it came to happen.

Here are some notes for the future.

[:jrmuizel] pointed out that [some other processes already have ACG with ASAN](https://searchfox.org/mozilla-central/source/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#1238). They are using `SetDelayedProcessMitigations` to achieve that, meaning that the mitigation will be applied after initialization (in particular, after ASAN initialization). Since the code to do this already exists, we could consider using `SetDelayedProcessMitigations` to enable ACG in ASAN builds here too, mostly for the sake of having consistent behavior between the two kinds of builds and not really for a security reason (so, this is much lower priority compared to doing it for release builds).

Regarding release builds however, if everything works with the non-delayed approach, I'd recommend keeping it non-delayed for them. The security impact is better with a non-delayed ACG. The problem I see with enabling the mitigation as delayed is that I think the legitimate code that runs before the mitigation is applied is allowed to allocate RWX memory that may survive for the rest of the life of the process. I don't think delayed ACG would catch this if it came to happen.