riscv64 hwasan: tag field / behavior does not adhere to ratified zjpm spec

[shuffle2]

llvm claims support for ratified riscv extensions related to pointer masking: #96715

While this is true in the sense that (as noted in #79929 ) llvm is not responsible for controlling or inspecting PMM, features in llvm such as hwasan don't really align to the ratified spec

Specifically, hwasan in llvm currently uses values for PointerTagShift and TagMaskByte which make the tag on riscv64 the top 8bits.

The ratified spec allows the ignored bits to be 0 bits (PM is disabled), 7bits (intended for Sv57), or 16bits (otherwise). The topmost non-masked bit is sign-extended in the effective address when virtual address translation is enabled. The masked bits are zero-filled if virtual address translation is not enabled.

It seems this leaves current hwasan implementation in such state if running on hardware supporting ratified version of zjpm:

• PMLEN=7 will always break code, since low bit of the tag overlaps either the sign bit or high bit of physical address.
• PMLEN=16 should work with existing code, although not all tag space will be utilized, and the hwasan runtime / end user code may need tweaking.

Some riscv cores are known to implement unratified version of PM - possibly because they were designed before ratified spec. For this case, any changes to hwasan to support the ratified spec should be backwards compatible with existing behavior of masking top 8bits and not expecting hardware to sign-extend any bits. Additionally, hwasan runtime implementations may not desire to store 16bit tag per granule, instead using 8bits for space saving, even though PMLEN=16.

16bit tags will also be problematic for global variables because the current format of hwasan_globals does not allow tag size to grow beyond 8bits. ( @pcc @fmayer for vis, lmk if i should untag you :))

I'm creating this issue to get feedback and see if anyone is tackling the issue already.