Hacker News Reader

Comment by verdagon | Hacker News Reader

I do a lot in the PL space, and Zig has me pretty excited. I think Zig, paired with memory tagging for memory safety, could be a killer combination one day.

View on HN

have you looked at ParaSail. It's designed by the guy who led the Ada 9x ('95) design team and it's unique in being pointer free (not just like in ada or Fortran where pointers are discouraged, but the language literally does not have them). Instead of pointers it has grow-able types based on memory tagging. It's specified such that each sub-expression can be safely executed in parallel.

ParaSail development has stagnated after he joined Ada Core, have any other progresses happened since then?

Given that memory tagging for memory safety has been designed for C and C++, already exists for SPARC ADI, and is getting adoption across ARM based devices specially iOS and Android ones, what is the improvement Zig brings to the table on that regard?

I can imagine Zig using memory tagging at a more granular level: imagine changing a 16B union's tag when assigning it. C and C++ only do it per-allocation IIRC.

It has nothing to do with C or C++, rather OS support.

What I'm saying is, a new language can use memory tagging more effectively, if it decides when to scramble a tag.

Hardware memory tagging is done via OS APIs, the language has nothing to do with it.

The OS decides when what.

Was on my phone before, but now I can give a more in-depth reply =)

So far, memory tagging is only done per allocation from malloc or alloca. The compiler backend inserts special new instructions (such as STG) to scramble the tag for a specific 16B "block". [0]

I propose that the zig compiler _frontend_ can also insert some STG instructions. Whenever the user does an = operation to replace one union member with another, we should do an STG on the union's containing blocks. Suddenly, we are much more memory safe, pretty much closing the gap with Rust.

Indeed, only some CPUs support memory tagging, and that's unfortunate. However, that doesn't stop us from using it where it is supported ;) if for nothing else, its help as a debugging tool would be amazing, like a much faster ASan or valgrind.

[0] https://developer.arm.com/-/media/Arm%20Developer%20Communit...

Here is how it works for SPARC,

https://docs.oracle.com/cd/E53394_01/html/E54815/gqajs.html

https://docs.oracle.com/cd/E86824_01/html/E54765/adi-2.html

https://docs.oracle.com/cd/E86824_01/html/E54766/adi-3c.html

https://docs.oracle.com/cd/E37838_01/html/E61021/sysauth-adi...

And for iOS,

https://developer.apple.com/documentation/security/preparing...

https://developer.apple.com/documentation/security/hardened_...

And for Android,

https://developer.android.com/ndk/guides/hwasan

So you cannot just assume that calling a couple of Assembly instructions from userspace will do for hardware memory tagging.

Thanks for sharing these! I see what you mean now. And it's especially unfortunate that Android needs an entirely different OS build.

iOS works a bit more like I expected, though they don't list the instructions we might use to scramble the tags for a block of memory like the ARM paper's STG instruction does. I wonder if that might be possible one day.

Reply on news.ycombinator.com