RFC: Change what assert does on error

[Richard (Rikki) Andrew Cattermole]

On 03/07/2025 11:26 AM, Walter Bright wrote:
>     and rollback to that point... which is what stack unwinding achieves.
> 
> Stack unwinding may be just what the malware needs to install itself. 
> The stack may be corrupt, which is why Error does not guarantee running 
> destructors on the stack.

I've been looking into this and I am failing to see this as a risk.

Here is why:

1. Due to MMU's which we all love, you can't jump to some random address 
and execute. The execute flag isn't set, and setting it is a complex bit 
of a function call. To do in sequence with a write. Extremely unlikely, 
to the point that we can consider this one solved. A JIT will typically 
set as writable, write then reflag as readable+executable without 
executable prior jumping. So the likelihood of write + execute on ANY 
memory in a process is basically zero.

2. MSVC has the /GS flag to enable protections against injections from 
corrupting the stack itself. So does LLVM although we don't enable them 
(ssp) https://llvm.org/docs/LangRef.html#function-attributes

3. According to Microsoft MSVC has had mitigations in place since XP for 
all these issues. 
https://msrc.microsoft.com/blog/2013/10/software-defense-mitigating-stack-corruption-vulnerabilties/

4. Microsoft are so certain that this is solved, they legally REQUIRE 
that you can handle all errors in a process to publish on the Microsoft 
App Store. "The product must handle exceptions raised by any of the 
managed or native system APIs and remain responsive to user input after 
the exception is handled." 
https://learn.microsoft.com/en-us/windows/apps/publish/store-policies#104-usability

What I am missing here is any evidence that shows the use of stack 
corruption, or stack unwinding cannot be mitigated with code gen or is 
inherent in our existing execution environment.

Do you have any evidence that would help inform opinions on these topics 
that is current?