[OffTopic] A vulnerability postmortem on Network Security Services

[Paulo Pinto]

On Friday, 3 December 2021 at 10:32:33 UTC, Ola Fosheim Grøstad 
wrote:
> On Friday, 3 December 2021 at 10:16:49 UTC, Ola Fosheim Grøstad 
> wrote:
>> On Friday, 3 December 2021 at 10:04:11 UTC, Paulo Pinto wrote:
>>> Read my previous comment, 
>>> https://forum.dlang.org/post/anyicezeifvbuxurhwkz@forum.dlang.org
>>
>> Missed that Apple-link, yep, seems like they have it as an 
>> option for new devices if you use the right compiler switches.
>>
>
> It is also worth noting that based on the [ARM white 
> paper](https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Arm_Memory_Tagging_Extension_Whitepaper.pdf) we can deduce that it has some costs:
>
> 1. When initializing memory you have to tag all the memory, so 
> it should be combined with clearing the memory. This is a 
> performance issue for D as it does not zero-initialize memory 
> by default. (NaN vs 0.0 for floats for instance)
>
> 2. You should keep the address space small, to avoid tagging 
> costs.
>
> 3. Avoid allocations/freeing of memory. This is an issue for 
> high level programming patterns. You might also run into 
> problems if you provide your own allocators! This is an issue 
> for D now that there seems to be a move towards using custom 
> allocators.
>
> 4. Avoid unused buffer-space on the stack, as unused space has 
> to be tagged anyway.
>
> 5. Alignment of tagged stack memory of 16 bytes.
>
> If memory tagging is to be enabled for D it seems to have:
>
> - language implications (switch to zero initialization as the 
> default).
>
> - library implications (allocators have to do tagging correctly)
>
> - runtime implications (allocators and how to deal with 
> "tagging exceptions")
>
> - compiler implications (stack layout and tagging)

Note that on platforms like iOS and Android, going forward, those 
considerations don't matter at the language level, because the 
whole stack is using it.

Other examples would be Solaris SPARC ADI, IBM i TIMI, z/OS 
language environments, ClearPath MCP.

So any third party language needs to plays along if it wants to 
target the platform, no matter what.

These decisions have been taken because the costs outweight the 
security implications of not being able to fix C flaws at the 
language level (or the languages copy-paste compatible with it), 
and finally we have some companies with enough industry power 
that are feeling the money being lost fixing all those CVEs.