Passing tagged addresses to the kernel¶

All interpretation of userspace memory addresses by the kernel assumesan address tag of 0x00, unless the application enables the AArch64Tagged Address ABI explicitly(Documentation/arm64/tagged-address-abi.rst).

This includes, but is not limited to, addresses found in:

• pointer arguments to system calls, including pointers in structurespassed to system calls,
• the stack pointer (sp), e.g. when interpreting it to deliver asignal,
• the frame pointer (x29) and frame records, e.g. when interpretingthem to generate a backtrace or call graph.

Using non-zero address tags in any of these locations when theuserspace application did not enable the AArch64 Tagged Address ABI mayresult in an error code being returned, a (fatal) signal being raised,or other modes of failure.

For these reasons, when the AArch64 Tagged Address ABI is disabled,passing non-zero address tags to the kernel via system calls isforbidden, and using a non-zero address tag for sp is stronglydiscouraged.

Programs maintaining a frame pointer and frame records that use non-zeroaddress tags may suffer impaired or inaccurate debug and profilingvisibility.

Preserving tags¶

Non-zero tags are not preserved when delivering signals. This means thatsignal handlers in applications making use of tags cannot rely on thetag information for user virtual addresses being maintained for fieldsinside siginfo_t. One exception to this rule is for signals raised inresponse to watchpoint debug exceptions, where the tag information willbe preserved.

The architecture prevents the use of a tagged PC, so the upper byte willbe set to a sign-extension of bit 55 on exception return.

This behaviour is maintained when the AArch64 Tagged Address ABI isenabled.

Other considerations¶

Special care should be taken when using tagged pointers, since it islikely that C compilers will not hazard two virtual addresses differingonly in the upper byte.