You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several PAuth-specific options in clang: -msign-return-address, -fptrauth-*, a meta-option -mbranch-protection=pauthabi, etc. Currently, clang does no verify if PAuth subtarget feature is enabled when such options are passed. Given that backend also does not verify that, we only fail in assertion during verifying machine instructions if some pac-specific instruction are emitted for pac-disabled target.
#62 clearly shows that backend is a bad place to add such verification since there are way too many places where checks should be added. Also, it's better to fail as early as we can.
The verification should probably exploit the HasPAuth field of AArch64TargetInfo (see clang/lib/Basic/Targets/AArch64.h). It should probably also be set in AArch64TargetInfo::handleTargetFeatures when subtarget is greater or equal than armv8.
Software authentication should also be taken into account so we don't fail when a user tries to enable that.
There are several PAuth-specific options in clang:
-msign-return-address
,-fptrauth-*
, a meta-option-mbranch-protection=pauthabi
, etc. Currently, clang does no verify if PAuth subtarget feature is enabled when such options are passed. Given that backend also does not verify that, we only fail in assertion during verifying machine instructions if some pac-specific instruction are emitted for pac-disabled target.#62 clearly shows that backend is a bad place to add such verification since there are way too many places where checks should be added. Also, it's better to fail as early as we can.
The verification should probably exploit the
HasPAuth
field ofAArch64TargetInfo
(see clang/lib/Basic/Targets/AArch64.h). It should probably also be set inAArch64TargetInfo::handleTargetFeatures
when subtarget is greater or equal than armv8.Software authentication should also be taken into account so we don't fail when a user tries to enable that.
See also https://reviews.llvm.org/D115501 for similar checks implementation.
The text was updated successfully, but these errors were encountered: