On Friday, 3 December 2021 at 10:16:49 UTC, Ola Fosheim Grøstad wrote:

It is also worth noting that based on the ARM white paper 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)

On Friday, 3 December 2021 at 10:32:33 UTC, Ola Fosheim Grøstad wrote:

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.

On Friday, 3 December 2021 at 12:08:59 UTC, Paulo Pinto wrote:

So you are saying that this will be required and not an option once all CPUs are capable? Right now it seems to be opt-in?

That is certainly an interesting perspective. If this will be required on iOS it probably will be required on MacOS at some point too.

On Friday, 3 December 2021 at 12:27:11 UTC, Ola Fosheim Grøstad wrote:

Yes that is the whole point.

https://docs.oracle.com/cd/E37838_01/html/E61021/sysauth-secext.html#OSSADsysauth-secext

So on Solaris, the admin gets to say if the OS runs the process under hardware memory tagging or not.

On Android,

https://source.android.com/devices/tech/debug/tagged-pointers

Note the "all heap allocations" on the documentation and it being enabled on Pixel 4 and later devices.

You can guess similar documentation for the other links I provided earlier.

On Friday, 3 December 2021 at 13:33:22 UTC, Paulo Pinto wrote:

Why would it be the whole point, though? Processes are isolated so bugs do not matter for things like games where speed is more important?

Yes, that was pretty clear. MTE will be required in the future on Android devices.

Well. Seems like the only sensible initialization strategy is to use zero as the default from now on since that is what will be provided by the tagging allocator on all ARM devices… as far as I can tell.

On Friday, 3 December 2021 at 13:44:49 UTC, Ola Fosheim Grøstad wrote:

That said, that applies to heap allocations and not the stack, I think. I don't see how they can enforce it on the stack as the OS cannot know what the object boundaries on the stack are.

On Friday, 3 December 2021 at 13:44:49 UTC, Ola Fosheim Grøstad wrote:

Bugs matter for things like games as well, single player games without networking capabilities are a tiny market, and then there are all those MMO servers, with game items that actually map to real money.

I bet a game publisher loosing their MMO servers due to a buffer overrun exploited on the game client thanks to some optimizations won't be too much happy about it.

On Friday, 3 December 2021 at 13:54:34 UTC, Paulo Pinto wrote:

It makes sense for MMOs in general, anything that can make cheating a little bit harder also makes sense in that domain.

On Friday, 3 December 2021 at 06:57:49 UTC, Tejas wrote:

I understand. It was during this conversation that I realized D has no strategy that will allow it to evolve (and no strategy to develop such a strategy). The cost of making an extreme change like safe by default is that you have to accept a compiler flag or some other compromise. That seems to be off the table, which makes it hard to see D being much different in 2041 than it is now.