[OffTopic] A vulnerability postmortem on Network Security Services

[Ola Fosheim Grøstad]

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)