Firefox and Chrome enable various Windows exploit mitigations using the HeapSetInformation and SetProcessMitigationPolicy APIs. Some of these mitigations may be useful (or at least harmless) for the Rust compiler to enable by default in Rust programs on Windows.
Is enabling these mitigations something the Rust team would consider?
While some of these “belt and suspenders” mitigations might not be necessary for safe Rust code, they could still protect against issues in unsafe Rust code, third-party C++ libraries, or third-party DLLs injected into the current process. In contrast, I believe Go programs do not enable ASLR/PIE by default.
Some of these mitigations could cause compatibility issues with existing Rust code (e.g. changing assumptions about the DLL search path) or third-party C++ code (e.g. that have “harmless” bugs such as passing an invalid or already closed HANDLE to CloseHandle).
Most of these mitigations can’t be disabled once enabled, so there would be no escape hatch if a Rust program needed to use a buggy third-party C++ library (in the same process).
Some example mitigations:
-
Use HeapEnableTerminationOnCorruption to terminate the process when Windows system heap corruption is detected.
-
Use SetDefaultDllDirectories to remove the current directory from the DLL search path.
-
Use SetProcessDEPPolicy to enable Data Execution Prevention (DEP) for 32-bit programs. It’s enabled by default in 64-bit programs.
-
Use ProcessASLRPolicy to harden the ASLR policy, such as forcing DLL relocations.
-
Use ProcessStrictHandleCheckPolicy to raise an exception when an invalid HANDLE is passed to a Windows API.
-
Use ProcessSystemCallDisablePolicy to disallow Win32k’s NTUser/GDI system calls.
-
Use ProcessExtensionPointDisablePolicy to disable legacy extension point DLLs.
… There are more but these are some basic mitigations that would probably not cause significant compatibility issues.