malloc and buffer overflow attacks

[max haughton]

On Saturday, 1 January 2022 at 01:44:42 UTC, Era Scarecrow wrote:
> On Friday, 31 December 2021 at 00:13:56 UTC, Walter Bright 
> wrote:
>> What if `len*T.sizeof` overflows? malloc() will succeed, but 
>> the result will be too small for the data.
>
>  Makes me wish access to the raw multiplication result and 
> carry flags may have been useful here in some way, although the 
> language might not have liked it.
>
>  As a quick overview for non-ASM savvy types, x86 will take 2 
> arguments, you put one argument in AX and the other you pass to 
> mul. So...
>
> ```
> mov AX, 0x155;
> mov BX, 0x123;
> mul BX; //result: AX=839F, DX=0001
> ```
>
> The result of which is going to be in AX:DX, where the overflow 
> is put in DX (*if any*), letting you get a 32bit result from 
> 16bit registers (*or in 64 bit machines you'd get a 128bit 
> result*).
>
> Most modern languages just ignore the upper result though, 
> which brings us to the following topic. In the 16bit example 
> above you'd be short 64k.
>
> Too bad we don't have the cent type yet. Otherwise I'd think 
> using ulong and calculating the result and passing that would 
> be the safest, (*assuming malloc would take a 64bit result*), 
> otherwise checking the upper bits for if it's too big.

Cleanly expressing access to the flags sounds quite hard, also 
note that some architectures don't have flags, and some other 
architectures make writing to the flags optional.

ARM chose optional, it might be one of a few things that could 
lead them beating RISC-V in the long run (both as a design 
decision but also as a point about embracing pragmatism)