From: invalid@invalid.invalid   
      
   Pancho  writes:   
   > On 2/5/26 14:14, The Natural Philosopher wrote:   
   >> The first is of course implementation specific. C can specify a data   
   >> stack separate from a program stack and avoid code corruption,   
   >> leaving only data corruption...   
   >   
   > Can it?  Naively, I would have thought C was normally built on top of   
   > native assembler function calls, which dictates a shared stack.   
   > Obviously you could implement a function call independent of   
   > assembler, but does anyone, in practice?   
      
   You’d leave the call stack as it is (i.e. CALL and RET, on x86) and use   
   another register to manage the data stack (maybe rbp on x86). I’ve never   
   heard of anyone doing it for C but I don’t think there’s any fundamental   
   obsctacle to it. It’d be a distinct ABI, so not particularly convenient   
   to integrate into existing systems.   
      
   FORTH normally has separate data and return stacks.   
      
   It wouldn’t be a silver bullet. The ‘code corruption’ that involves the   
   stack is overwriting the addresses of code, not the code itself, and the   
   addresses of code includes function pointers (which appear in the data   
   stack and heap) as well as return addresses. There are other targets in   
   the data stack as well.   
      
   The mitigations that have historically been used are ASLR (making stack   
   and code addresses impractical to predict) and mapping stacks and other   
   data pages without execute permission. Attackers respond by looking for   
   bugs that leak internal addresses (to bypass ASLR) and finding   
   pre-existing code that does what they need (“return-oriented program”).   
      
   --   
   https://www.greenend.org.uk/rjk/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)