Re: [hatari-devel] windows build failing on cirrus-ci

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Thu, 25 Apr 2024 03:09:15 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 24.4.2024 20.03, Christian Zietz wrote:
> > Nicolas Pomarède schrieb:
> >   
> >> Yes, the problem is in the new function "loadSymFile"
> >>
> >> I don't know if this is supported in a more recent version of visual C
> >> than the one used in cirrus-ci,  
> > 
> > I am always very cautions about variable length arrays, anyway. Like any 
> > local variable, they are allocated on the stack; but with a VLA one can 
> > only cross one's fingers to hope that it fits without causing a stack 
> > exhaustion.  
> 
> AFAIK all the modern OSes have virtual memory and automatically grow the 
>   stack as needed (in main thread, and Hatari code is not threaded).
> 
> I.e. if (main thread) stack runs out, either process has ran out of 
> (64-bit) address space, or machine it's running, is out of RAM+swap and 
> anything at all will fail.

I think it's a little bit more than that: If you are using variable length
arrays on the stack in a program where you process untrusted data (imagine
someone would write a malicious PRG and tricks you into using it), the
variable length arrays could provide a way to the malicious code to control
the stack layout, which could be used for exploits. It's unlikely for the
Hatari case, but still, maybe it's a better habbit indeed to simply avoid
variable length arrays on the stack in general.

(For some funny reasons, Microsoft still allows alloca() and we used it in
the past in Hatari already to workaround the problems with variable-length
arrays, see e.g. commit 76c855b5b237c5 ... but maybe we should forbid
alloca() in the Hatari code nowadays, too...)

 Thomas