* [PATCH 0/2] Support HWASAN with Intel LAM @ 2022-11-11 1:26 liuhongt 2022-11-11 1:26 ` [PATCH 1/2] Implement hwasan target_hook liuhongt ` (3 more replies) 0 siblings, 4 replies; 11+ messages in thread From: liuhongt @ 2022-11-11 1:26 UTC (permalink / raw) To: gcc-patches; +Cc: crazylht, hjl.tools, ubizjak 2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several target hooks(Many thanks to their work) so other backends can do similar things if they have similar feature. Intel LAM(linear Address Masking)[3 Charpter 14] supports similar feature with the upper bits of pointers can be used as metadata, LAM support two modes: LAM_U48:bits 48-62 can be used as metadata LAM_U57:bits 57-62 can be used as metedata. These 2 patches mainly support those target hooks, but HWASAN is not really enabled until the final decision for the LAM kernel interface which may take quite a long time. We have verified our patches with a "fake" interface locally[4], and decided to push the backend patches to the GCC13 to make other HWASAN developper's work easy. [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html [3] https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? liuhongt (2): Implement hwasan target_hook. Enable hwasan for x86-64. gcc/config/i386/i386-expand.cc | 12 ++++ gcc/config/i386/i386-options.cc | 3 + gcc/config/i386/i386-opts.h | 6 ++ gcc/config/i386/i386-protos.h | 2 + gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ gcc/config/i386/i386.opt | 16 +++++ libsanitizer/configure.tgt | 1 + 7 files changed, 163 insertions(+) -- 2.18.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2] Implement hwasan target_hook. 2022-11-11 1:26 [PATCH 0/2] Support HWASAN with Intel LAM liuhongt @ 2022-11-11 1:26 ` liuhongt 2022-11-30 5:21 ` [PATCH 1/2 V2] " liuhongt 2022-11-11 1:26 ` [PATCH 2/2] Enable hwasan for x86-64 liuhongt ` (2 subsequent siblings) 3 siblings, 1 reply; 11+ messages in thread From: liuhongt @ 2022-11-11 1:26 UTC (permalink / raw) To: gcc-patches; +Cc: crazylht, hjl.tools, ubizjak gcc/ChangeLog: * config/i386/i386-opts.h (enum lam_type): New enum. * config/i386/i386.c (ix86_memtag_can_tag_addresses): New. (ix86_memtag_set_tag): Ditto. (ix86_memtag_extract_tag): Ditto. (ix86_memtag_add_tag): Ditto. (ix86_memtag_tag_size): Ditto. (ix86_memtag_untagged_pointer): Ditto. (TARGET_MEMTAG_CAN_TAG_ADDRESSES): New. (TARGET_MEMTAG_ADD_TAG): Ditto. (TARGET_MEMTAG_SET_TAG): Ditto. (TARGET_MEMTAG_EXTRACT_TAG): Ditto. (TARGET_MEMTAG_UNTAGGED_POINTER): Ditto. (TARGET_MEMTAG_TAG_SIZE): Ditto. (IX86_HWASAN_SHIFT): Ditto. (IX86_HWASAN_TAG_SIZE): Ditto. * config/i386/i386-expand.c (ix86_expand_call): Untag code pointer. * config/i386/i386-options.c (ix86_option_override_internal): Error when enable -mlam=[u48|u57] for 32-bit code. * config/i386/i386.opt: Add -mlam=[none|u48|u57]. * config/i386/i386-protos.h (ix86_memtag_untagged_pointer): Declare. (ix86_memtag_can_tag_addresses): Ditto. --- gcc/config/i386/i386-expand.cc | 12 ++++ gcc/config/i386/i386-options.cc | 3 + gcc/config/i386/i386-opts.h | 6 ++ gcc/config/i386/i386-protos.h | 2 + gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ gcc/config/i386/i386.opt | 16 +++++ 6 files changed, 162 insertions(+) diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc index 9c92b07d5cd..1af50c86c39 100644 --- a/gcc/config/i386/i386-expand.cc +++ b/gcc/config/i386/i386-expand.cc @@ -92,6 +92,7 @@ along with GCC; see the file COPYING3. If not see #include "i386-options.h" #include "i386-builtins.h" #include "i386-expand.h" +#include "asan.h" /* Split one or more double-mode RTL references into pairs of half-mode references. The RTL can be REG, offsettable MEM, integer constant, or @@ -9436,6 +9437,17 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1, fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (word_mode, fnaddr)); } + /* PR100665: Hwasan may tag code pointer which is not supported by LAM, + mask off code pointers here. + TODO: also need to handle indirect jump. */ + if (ix86_memtag_can_tag_addresses () && !fndecl + && sanitize_flags_p (SANITIZE_HWADDRESS)) + { + rtx untagged_addr = ix86_memtag_untagged_pointer (XEXP (fnaddr, 0), + NULL_RTX); + fnaddr = gen_rtx_MEM (QImode, untagged_addr); + } + call = gen_rtx_CALL (VOIDmode, fnaddr, callarg1); if (retval) diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc index e5c77f3a84d..b59ed5aee45 100644 --- a/gcc/config/i386/i386-options.cc +++ b/gcc/config/i386/i386-options.cc @@ -2006,6 +2006,9 @@ ix86_option_override_internal (bool main_args_p, if (TARGET_UINTR && !TARGET_64BIT) error ("%<-muintr%> not supported for 32-bit code"); + if (ix86_lam_type && !TARGET_LP64) + error ("%<-mlam=%> option: [u48|u57] not supported for 32-bit code"); + if (!opts->x_ix86_arch_string) opts->x_ix86_arch_string = TARGET_64BIT_P (opts->x_ix86_isa_flags) diff --git a/gcc/config/i386/i386-opts.h b/gcc/config/i386/i386-opts.h index 8f71e89fa9a..d3bfeed0af2 100644 --- a/gcc/config/i386/i386-opts.h +++ b/gcc/config/i386/i386-opts.h @@ -128,4 +128,10 @@ enum harden_sls { harden_sls_all = harden_sls_return | harden_sls_indirect_jmp }; +enum lam_type { + lam_none = 0, + lam_u48 = 1, + lam_u57 +}; + #endif diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h index 5318fc7fddf..2533f17006d 100644 --- a/gcc/config/i386/i386-protos.h +++ b/gcc/config/i386/i386-protos.h @@ -227,6 +227,8 @@ extern void ix86_expand_atomic_fetch_op_loop (rtx, rtx, rtx, enum rtx_code, bool, bool); extern void ix86_expand_cmpxchg_loop (rtx *, rtx, rtx, rtx, rtx, rtx, bool, rtx_code_label *); +extern rtx ix86_memtag_untagged_pointer (rtx, rtx); +extern bool ix86_memtag_can_tag_addresses (void); #ifdef TREE_CODE extern void init_cumulative_args (CUMULATIVE_ARGS *, tree, rtx, tree, int); diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index f8586499cd1..e6609cc12bb 100644 --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -24260,6 +24260,111 @@ ix86_push_rounding (poly_int64 bytes) return ROUND_UP (bytes, UNITS_PER_WORD); } +/* Use 8 bits metadata start from bit48 for LAM_U48, + 6 bits metadat start from bit57 for LAM_U57. */ +#define IX86_HWASAN_SHIFT (ix86_lam_type == lam_u48 \ + ? 48 \ + : (ix86_lam_type == lam_u57 ? 57 : 0)) +#define IX86_HWASAN_TAG_SIZE (ix86_lam_type == lam_u48 \ + ? 8 \ + : (ix86_lam_type == lam_u57 ? 6 : 0)) + +/* Implement TARGET_MEMTAG_CAN_TAG_ADDRESSES. */ +bool +ix86_memtag_can_tag_addresses () +{ + return ix86_lam_type != lam_none && TARGET_LP64; +} + +/* Implement TARGET_MEMTAG_TAG_SIZE. */ +unsigned char +ix86_memtag_tag_size () +{ + return IX86_HWASAN_TAG_SIZE; +} + +/* Implement TARGET_MEMTAG_SET_TAG. */ +rtx +ix86_memtag_set_tag (rtx untagged, rtx tag, rtx target) +{ + /* default_memtag_insert_random_tag may + generate tag with value more than 6 bits. */ + if (ix86_lam_type == lam_u57) + { + unsigned HOST_WIDE_INT and_imm + = (HOST_WIDE_INT_1U << IX86_HWASAN_TAG_SIZE) - 1; + + emit_insn (gen_andqi3 (tag, tag, GEN_INT (and_imm))); + } + tag = expand_simple_binop (Pmode, ASHIFT, tag, + GEN_INT (IX86_HWASAN_SHIFT), NULL_RTX, + /* unsignedp = */1, OPTAB_WIDEN); + rtx ret = expand_simple_binop (Pmode, IOR, untagged, tag, target, + /* unsignedp = */1, OPTAB_DIRECT); + return ret; +} + +/* Implement TARGET_MEMTAG_EXTRACT_TAG. */ +rtx +ix86_memtag_extract_tag (rtx tagged_pointer, rtx target) +{ + rtx tag = expand_simple_binop (Pmode, LSHIFTRT, tagged_pointer, + GEN_INT (IX86_HWASAN_SHIFT), target, + /* unsignedp = */0, + OPTAB_DIRECT); + rtx ret = gen_reg_rtx (QImode); + /* Mask off bit63 when LAM_U57. */ + if (ix86_lam_type == lam_u57) + { + unsigned HOST_WIDE_INT and_imm + = (HOST_WIDE_INT_1U << IX86_HWASAN_TAG_SIZE) - 1; + emit_insn (gen_andqi3 (ret, gen_lowpart (QImode, tag), + gen_int_mode (and_imm, QImode))); + } + else + emit_move_insn (ret, gen_lowpart (QImode, tag)); + return ret; +} + +/* The default implementation of TARGET_MEMTAG_UNTAGGED_POINTER. */ +rtx +ix86_memtag_untagged_pointer (rtx tagged_pointer, rtx target) +{ + /* Leave bit63 alone. */ + rtx tag_mask = gen_int_mode (((HOST_WIDE_INT_1U << IX86_HWASAN_SHIFT) + + (HOST_WIDE_INT_1U << 63) - 1), + Pmode); + rtx untagged_base = expand_simple_binop (Pmode, AND, tagged_pointer, + tag_mask, target, true, + OPTAB_DIRECT); + gcc_assert (untagged_base); + return untagged_base; +} + +/* Implement TARGET_MEMTAG_ADD_TAG. */ +rtx +ix86_memtag_add_tag (rtx base, poly_int64 offset, unsigned char tag_offset) +{ + rtx base_tag = gen_reg_rtx (QImode); + rtx base_addr = gen_reg_rtx (Pmode); + rtx tagged_addr = gen_reg_rtx (Pmode); + rtx new_tag = gen_reg_rtx (QImode); + unsigned HOST_WIDE_INT and_imm + = (HOST_WIDE_INT_1U << IX86_HWASAN_SHIFT) - 1; + + /* When there's "overflow" in tag adding, + need to mask the most significant bit off. */ + emit_move_insn (base_tag, ix86_memtag_extract_tag (base, NULL_RTX)); + emit_move_insn (base_addr, + ix86_memtag_untagged_pointer (base, NULL_RTX)); + emit_insn (gen_add2_insn (base_tag, gen_int_mode (tag_offset, QImode))); + emit_move_insn (new_tag, base_tag); + emit_insn (gen_andqi3 (new_tag, new_tag, gen_int_mode (and_imm, QImode))); + emit_move_insn (tagged_addr, + ix86_memtag_set_tag (base_addr, new_tag, NULL_RTX)); + return plus_constant (Pmode, tagged_addr, offset); +} + /* Target-specific selftests. */ #if CHECKING_P @@ -25054,6 +25159,24 @@ ix86_libgcc_floating_mode_supported_p # define TARGET_ASM_RELOC_RW_MASK ix86_reloc_rw_mask #endif +#undef TARGET_MEMTAG_CAN_TAG_ADDRESSES +#define TARGET_MEMTAG_CAN_TAG_ADDRESSES ix86_memtag_can_tag_addresses + +#undef TARGET_MEMTAG_ADD_TAG +#define TARGET_MEMTAG_ADD_TAG ix86_memtag_add_tag + +#undef TARGET_MEMTAG_SET_TAG +#define TARGET_MEMTAG_SET_TAG ix86_memtag_set_tag + +#undef TARGET_MEMTAG_EXTRACT_TAG +#define TARGET_MEMTAG_EXTRACT_TAG ix86_memtag_extract_tag + +#undef TARGET_MEMTAG_UNTAGGED_POINTER +#define TARGET_MEMTAG_UNTAGGED_POINTER ix86_memtag_untagged_pointer + +#undef TARGET_MEMTAG_TAG_SIZE +#define TARGET_MEMTAG_TAG_SIZE ix86_memtag_tag_size + static bool ix86_libc_has_fast_function (int fcode ATTRIBUTE_UNUSED) { #ifdef OPTION_GLIBC diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt index 415c52e1bb4..2c5fc361d07 100644 --- a/gcc/config/i386/i386.opt +++ b/gcc/config/i386/i386.opt @@ -1246,3 +1246,19 @@ Support PREFETCHI built-in functions and code generation. mraoint Target Mask(ISA2_RAOINT) Var(ix86_isa_flags2) Save Support RAOINT built-in functions and code generation. + +mlam= +Target RejectNegative Joined Enum(lam_type) Var(ix86_lam_type) Init(lam_none) +-mlam=[none|u48|u57] Instrument meta data position in user data pointers. + +Enum +Name(lam_type) Type(enum lam_type) UnknownError(unknown lam type %qs) + +EnumValue +Enum(lam_type) String(none) Value(lam_none) + +EnumValue +Enum(lam_type) String(u48) Value(lam_u48) + +EnumValue +Enum(lam_type) String(u57) Value(lam_u57) -- 2.18.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2 V2] Implement hwasan target_hook. 2022-11-11 1:26 ` [PATCH 1/2] Implement hwasan target_hook liuhongt @ 2022-11-30 5:21 ` liuhongt 0 siblings, 0 replies; 11+ messages in thread From: liuhongt @ 2022-11-30 5:21 UTC (permalink / raw) To: gcc-patches; +Cc: crazylht, hjl.tools, ubizjak Update in V2: Add documentation for -mlam={none,u48,u57} to x86 options in invoke.texi. gcc/ChangeLog: * doc/invoke.texi (x86 options): Document -mlam={none,u48,u57}. * config/i386/i386-opts.h (enum lam_type): New enum. * config/i386/i386.c (ix86_memtag_can_tag_addresses): New. (ix86_memtag_set_tag): Ditto. (ix86_memtag_extract_tag): Ditto. (ix86_memtag_add_tag): Ditto. (ix86_memtag_tag_size): Ditto. (ix86_memtag_untagged_pointer): Ditto. (TARGET_MEMTAG_CAN_TAG_ADDRESSES): New. (TARGET_MEMTAG_ADD_TAG): Ditto. (TARGET_MEMTAG_SET_TAG): Ditto. (TARGET_MEMTAG_EXTRACT_TAG): Ditto. (TARGET_MEMTAG_UNTAGGED_POINTER): Ditto. (TARGET_MEMTAG_TAG_SIZE): Ditto. (IX86_HWASAN_SHIFT): Ditto. (IX86_HWASAN_TAG_SIZE): Ditto. * config/i386/i386-expand.c (ix86_expand_call): Untag code pointer. * config/i386/i386-options.c (ix86_option_override_internal): Error when enable -mlam=[u48|u57] for 32-bit code. * config/i386/i386.opt: Add -mlam=[none|u48|u57]. * config/i386/i386-protos.h (ix86_memtag_untagged_pointer): Declare. (ix86_memtag_can_tag_addresses): Ditto. --- gcc/config/i386/i386-expand.cc | 12 ++++ gcc/config/i386/i386-options.cc | 3 + gcc/config/i386/i386-opts.h | 6 ++ gcc/config/i386/i386-protos.h | 2 + gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ gcc/config/i386/i386.opt | 16 +++++ gcc/doc/invoke.texi | 9 ++- 7 files changed, 170 insertions(+), 1 deletion(-) diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc index d26e7e41445..0e94782165a 100644 --- a/gcc/config/i386/i386-expand.cc +++ b/gcc/config/i386/i386-expand.cc @@ -92,6 +92,7 @@ along with GCC; see the file COPYING3. If not see #include "i386-options.h" #include "i386-builtins.h" #include "i386-expand.h" +#include "asan.h" /* Split one or more double-mode RTL references into pairs of half-mode references. The RTL can be REG, offsettable MEM, integer constant, or @@ -9438,6 +9439,17 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1, fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (word_mode, fnaddr)); } + /* PR100665: Hwasan may tag code pointer which is not supported by LAM, + mask off code pointers here. + TODO: also need to handle indirect jump. */ + if (ix86_memtag_can_tag_addresses () && !fndecl + && sanitize_flags_p (SANITIZE_HWADDRESS)) + { + rtx untagged_addr = ix86_memtag_untagged_pointer (XEXP (fnaddr, 0), + NULL_RTX); + fnaddr = gen_rtx_MEM (QImode, untagged_addr); + } + call = gen_rtx_CALL (VOIDmode, fnaddr, callarg1); if (retval) diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc index 44dcccb0a73..25f21ac2a49 100644 --- a/gcc/config/i386/i386-options.cc +++ b/gcc/config/i386/i386-options.cc @@ -2033,6 +2033,9 @@ ix86_option_override_internal (bool main_args_p, if (TARGET_UINTR && !TARGET_64BIT) error ("%<-muintr%> not supported for 32-bit code"); + if (ix86_lam_type && !TARGET_LP64) + error ("%<-mlam=%> option: [u48|u57] not supported for 32-bit code"); + if (!opts->x_ix86_arch_string) opts->x_ix86_arch_string = TARGET_64BIT_P (opts->x_ix86_isa_flags) diff --git a/gcc/config/i386/i386-opts.h b/gcc/config/i386/i386-opts.h index 8f71e89fa9a..d3bfeed0af2 100644 --- a/gcc/config/i386/i386-opts.h +++ b/gcc/config/i386/i386-opts.h @@ -128,4 +128,10 @@ enum harden_sls { harden_sls_all = harden_sls_return | harden_sls_indirect_jmp }; +enum lam_type { + lam_none = 0, + lam_u48 = 1, + lam_u57 +}; + #endif diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h index e136f6ec175..abd123c9efc 100644 --- a/gcc/config/i386/i386-protos.h +++ b/gcc/config/i386/i386-protos.h @@ -228,6 +228,8 @@ extern void ix86_expand_atomic_fetch_op_loop (rtx, rtx, rtx, enum rtx_code, extern void ix86_expand_cmpxchg_loop (rtx *, rtx, rtx, rtx, rtx, rtx, bool, rtx_code_label *); extern rtx ix86_expand_fast_convert_bf_to_sf (rtx); +extern rtx ix86_memtag_untagged_pointer (rtx, rtx); +extern bool ix86_memtag_can_tag_addresses (void); #ifdef TREE_CODE extern void init_cumulative_args (CUMULATIVE_ARGS *, tree, rtx, tree, int); diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index 95babd93c9d..518cc9ffd1f 100644 --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -24274,6 +24274,111 @@ ix86_push_rounding (poly_int64 bytes) return ROUND_UP (bytes, UNITS_PER_WORD); } +/* Use 8 bits metadata start from bit48 for LAM_U48, + 6 bits metadat start from bit57 for LAM_U57. */ +#define IX86_HWASAN_SHIFT (ix86_lam_type == lam_u48 \ + ? 48 \ + : (ix86_lam_type == lam_u57 ? 57 : 0)) +#define IX86_HWASAN_TAG_SIZE (ix86_lam_type == lam_u48 \ + ? 8 \ + : (ix86_lam_type == lam_u57 ? 6 : 0)) + +/* Implement TARGET_MEMTAG_CAN_TAG_ADDRESSES. */ +bool +ix86_memtag_can_tag_addresses () +{ + return ix86_lam_type != lam_none && TARGET_LP64; +} + +/* Implement TARGET_MEMTAG_TAG_SIZE. */ +unsigned char +ix86_memtag_tag_size () +{ + return IX86_HWASAN_TAG_SIZE; +} + +/* Implement TARGET_MEMTAG_SET_TAG. */ +rtx +ix86_memtag_set_tag (rtx untagged, rtx tag, rtx target) +{ + /* default_memtag_insert_random_tag may + generate tag with value more than 6 bits. */ + if (ix86_lam_type == lam_u57) + { + unsigned HOST_WIDE_INT and_imm + = (HOST_WIDE_INT_1U << IX86_HWASAN_TAG_SIZE) - 1; + + emit_insn (gen_andqi3 (tag, tag, GEN_INT (and_imm))); + } + tag = expand_simple_binop (Pmode, ASHIFT, tag, + GEN_INT (IX86_HWASAN_SHIFT), NULL_RTX, + /* unsignedp = */1, OPTAB_WIDEN); + rtx ret = expand_simple_binop (Pmode, IOR, untagged, tag, target, + /* unsignedp = */1, OPTAB_DIRECT); + return ret; +} + +/* Implement TARGET_MEMTAG_EXTRACT_TAG. */ +rtx +ix86_memtag_extract_tag (rtx tagged_pointer, rtx target) +{ + rtx tag = expand_simple_binop (Pmode, LSHIFTRT, tagged_pointer, + GEN_INT (IX86_HWASAN_SHIFT), target, + /* unsignedp = */0, + OPTAB_DIRECT); + rtx ret = gen_reg_rtx (QImode); + /* Mask off bit63 when LAM_U57. */ + if (ix86_lam_type == lam_u57) + { + unsigned HOST_WIDE_INT and_imm + = (HOST_WIDE_INT_1U << IX86_HWASAN_TAG_SIZE) - 1; + emit_insn (gen_andqi3 (ret, gen_lowpart (QImode, tag), + gen_int_mode (and_imm, QImode))); + } + else + emit_move_insn (ret, gen_lowpart (QImode, tag)); + return ret; +} + +/* The default implementation of TARGET_MEMTAG_UNTAGGED_POINTER. */ +rtx +ix86_memtag_untagged_pointer (rtx tagged_pointer, rtx target) +{ + /* Leave bit63 alone. */ + rtx tag_mask = gen_int_mode (((HOST_WIDE_INT_1U << IX86_HWASAN_SHIFT) + + (HOST_WIDE_INT_1U << 63) - 1), + Pmode); + rtx untagged_base = expand_simple_binop (Pmode, AND, tagged_pointer, + tag_mask, target, true, + OPTAB_DIRECT); + gcc_assert (untagged_base); + return untagged_base; +} + +/* Implement TARGET_MEMTAG_ADD_TAG. */ +rtx +ix86_memtag_add_tag (rtx base, poly_int64 offset, unsigned char tag_offset) +{ + rtx base_tag = gen_reg_rtx (QImode); + rtx base_addr = gen_reg_rtx (Pmode); + rtx tagged_addr = gen_reg_rtx (Pmode); + rtx new_tag = gen_reg_rtx (QImode); + unsigned HOST_WIDE_INT and_imm + = (HOST_WIDE_INT_1U << IX86_HWASAN_SHIFT) - 1; + + /* When there's "overflow" in tag adding, + need to mask the most significant bit off. */ + emit_move_insn (base_tag, ix86_memtag_extract_tag (base, NULL_RTX)); + emit_move_insn (base_addr, + ix86_memtag_untagged_pointer (base, NULL_RTX)); + emit_insn (gen_add2_insn (base_tag, gen_int_mode (tag_offset, QImode))); + emit_move_insn (new_tag, base_tag); + emit_insn (gen_andqi3 (new_tag, new_tag, gen_int_mode (and_imm, QImode))); + emit_move_insn (tagged_addr, + ix86_memtag_set_tag (base_addr, new_tag, NULL_RTX)); + return plus_constant (Pmode, tagged_addr, offset); +} + /* Target-specific selftests. */ #if CHECKING_P @@ -25068,6 +25173,24 @@ ix86_libgcc_floating_mode_supported_p # define TARGET_ASM_RELOC_RW_MASK ix86_reloc_rw_mask #endif +#undef TARGET_MEMTAG_CAN_TAG_ADDRESSES +#define TARGET_MEMTAG_CAN_TAG_ADDRESSES ix86_memtag_can_tag_addresses + +#undef TARGET_MEMTAG_ADD_TAG +#define TARGET_MEMTAG_ADD_TAG ix86_memtag_add_tag + +#undef TARGET_MEMTAG_SET_TAG +#define TARGET_MEMTAG_SET_TAG ix86_memtag_set_tag + +#undef TARGET_MEMTAG_EXTRACT_TAG +#define TARGET_MEMTAG_EXTRACT_TAG ix86_memtag_extract_tag + +#undef TARGET_MEMTAG_UNTAGGED_POINTER +#define TARGET_MEMTAG_UNTAGGED_POINTER ix86_memtag_untagged_pointer + +#undef TARGET_MEMTAG_TAG_SIZE +#define TARGET_MEMTAG_TAG_SIZE ix86_memtag_tag_size + static bool ix86_libc_has_fast_function (int fcode ATTRIBUTE_UNUSED) { #ifdef OPTION_GLIBC diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt index aa8574e6b71..fb4e57ada7c 100644 --- a/gcc/config/i386/i386.opt +++ b/gcc/config/i386/i386.opt @@ -1250,3 +1250,19 @@ Support RAOINT built-in functions and code generation. munroll-only-small-loops Target Var(ix86_unroll_only_small_loops) Init(0) Save Enable conservative small loop unrolling. + +mlam= +Target RejectNegative Joined Enum(lam_type) Var(ix86_lam_type) Init(lam_none) +-mlam=[none|u48|u57] Instrument meta data position in user data pointers. + +Enum +Name(lam_type) Type(enum lam_type) UnknownError(unknown lam type %qs) + +EnumValue +Enum(lam_type) String(none) Value(lam_none) + +EnumValue +Enum(lam_type) String(u48) Value(lam_u48) + +EnumValue +Enum(lam_type) String(u57) Value(lam_u57) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index e312b5cef3d..dcecf6849b0 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -1448,7 +1448,7 @@ See RS/6000 and PowerPC Options. -mindirect-branch=@var{choice} -mfunction-return=@var{choice} @gol -mindirect-branch-register -mharden-sls=@var{choice} @gol -mindirect-branch-cs-prefix -mneeded -mno-direct-extern-access @gol --munroll-only-small-loops} +-munroll-only-small-loops -mlam=@var{choice}} @emph{x86 Windows Options} @gccoptlist{-mconsole -mcygwin -mno-cygwin -mdll @gol @@ -33857,6 +33857,13 @@ Controls conservative small loop unrolling. It is default enabled by O2, and unrolls loop with less than 4 insns by 1 time. Explicit -f[no-]unroll-[all-]loops would disable this flag to avoid any unintended unrolling behavior that user does not want. + +@item -mlam=@var{choice} +@opindex mlam +LAM(linear-address masking) allows special bits in the pointer to be used +for metadata. The default is @samp{none}. With @samp{u48}, pointer bits in +positions 62:48 can be used for metadata; With @samp{u57}, pointer bits in +positions 62:57 can be used for metadata. @end table @node x86 Windows Options -- 2.18.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] Enable hwasan for x86-64. 2022-11-11 1:26 [PATCH 0/2] Support HWASAN with Intel LAM liuhongt 2022-11-11 1:26 ` [PATCH 1/2] Implement hwasan target_hook liuhongt @ 2022-11-11 1:26 ` liuhongt 2022-11-28 3:35 ` [PATCH 0/2] Support HWASAN with Intel LAM Hongtao Liu 2022-11-28 14:40 ` Martin Liška 3 siblings, 0 replies; 11+ messages in thread From: liuhongt @ 2022-11-11 1:26 UTC (permalink / raw) To: gcc-patches; +Cc: crazylht, hjl.tools, ubizjak libsanitizer * configure.tgt: Enable hwasan for x86-64. --- libsanitizer/configure.tgt | 1 + 1 file changed, 1 insertion(+) diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt index 87d8a2c3820..72385a4a39d 100644 --- a/libsanitizer/configure.tgt +++ b/libsanitizer/configure.tgt @@ -29,6 +29,7 @@ case "${target}" in TSAN_SUPPORTED=yes LSAN_SUPPORTED=yes TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_amd64.lo + HWASAN_SUPPORTED=yes fi ;; powerpc*-*-linux*) -- 2.18.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] Support HWASAN with Intel LAM 2022-11-11 1:26 [PATCH 0/2] Support HWASAN with Intel LAM liuhongt 2022-11-11 1:26 ` [PATCH 1/2] Implement hwasan target_hook liuhongt 2022-11-11 1:26 ` [PATCH 2/2] Enable hwasan for x86-64 liuhongt @ 2022-11-28 3:35 ` Hongtao Liu 2022-11-28 7:12 ` Uros Bizjak 2022-11-28 14:40 ` Martin Liška 3 siblings, 1 reply; 11+ messages in thread From: Hongtao Liu @ 2022-11-28 3:35 UTC (permalink / raw) To: liuhongt; +Cc: gcc-patches, hjl.tools, ubizjak On Fri, Nov 11, 2022 at 9:26 AM liuhongt <hongtao.liu@intel.com> wrote: > > 2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several > target hooks(Many thanks to their work) so other backends can do similar > things if they have similar feature. > Intel LAM(linear Address Masking)[3 Charpter 14] supports similar feature with > the upper bits of pointers can be used as metadata, LAM support two modes: > LAM_U48:bits 48-62 can be used as metadata > LAM_U57:bits 57-62 can be used as metedata. > > These 2 patches mainly support those target hooks, but HWASAN is not really > enabled until the final decision for the LAM kernel interface which may take > quite a long time. We have verified our patches with a "fake" interface locally[4], and > decided to push the backend patches to the GCC13 to make other HWASAN developper's work > easy. > > [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html > [3] https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf > [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > Ok for trunk? I'll install 2 patches if there's no objections in next 7 days. > > liuhongt (2): > Implement hwasan target_hook. > Enable hwasan for x86-64. > > gcc/config/i386/i386-expand.cc | 12 ++++ > gcc/config/i386/i386-options.cc | 3 + > gcc/config/i386/i386-opts.h | 6 ++ > gcc/config/i386/i386-protos.h | 2 + > gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ > gcc/config/i386/i386.opt | 16 +++++ > libsanitizer/configure.tgt | 1 + > 7 files changed, 163 insertions(+) > > -- > 2.18.1 > -- BR, Hongtao ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] Support HWASAN with Intel LAM 2022-11-28 3:35 ` [PATCH 0/2] Support HWASAN with Intel LAM Hongtao Liu @ 2022-11-28 7:12 ` Uros Bizjak 0 siblings, 0 replies; 11+ messages in thread From: Uros Bizjak @ 2022-11-28 7:12 UTC (permalink / raw) To: Hongtao Liu; +Cc: liuhongt, gcc-patches, hjl.tools On Mon, Nov 28, 2022 at 4:35 AM Hongtao Liu <crazylht@gmail.com> wrote: > > On Fri, Nov 11, 2022 at 9:26 AM liuhongt <hongtao.liu@intel.com> wrote: > > > > 2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several > > target hooks(Many thanks to their work) so other backends can do similar > > things if they have similar feature. > > Intel LAM(linear Address Masking)[3 Charpter 14] supports similar feature with > > the upper bits of pointers can be used as metadata, LAM support two modes: > > LAM_U48:bits 48-62 can be used as metadata > > LAM_U57:bits 57-62 can be used as metedata. > > > > These 2 patches mainly support those target hooks, but HWASAN is not really > > enabled until the final decision for the LAM kernel interface which may take > > quite a long time. We have verified our patches with a "fake" interface locally[4], and > > decided to push the backend patches to the GCC13 to make other HWASAN developper's work > > easy. > > > > [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > > [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html > > [3] https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf > > [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > > Ok for trunk? > I'll install 2 patches if there's no objections in next 7 days. FYI, I have no objection. Uros. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] Support HWASAN with Intel LAM 2022-11-11 1:26 [PATCH 0/2] Support HWASAN with Intel LAM liuhongt ` (2 preceding siblings ...) 2022-11-28 3:35 ` [PATCH 0/2] Support HWASAN with Intel LAM Hongtao Liu @ 2022-11-28 14:40 ` Martin Liška 2022-11-29 2:10 ` H.J. Lu 2022-11-29 2:37 ` Hongtao Liu 3 siblings, 2 replies; 11+ messages in thread From: Martin Liška @ 2022-11-28 14:40 UTC (permalink / raw) To: liuhongt, gcc-patches; +Cc: crazylht, hjl.tools, ubizjak, Florian Weimer On 11/11/22 02:26, liuhongt via Gcc-patches wrote: > 2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several > target hooks(Many thanks to their work) so other backends can do similar > things if they have similar feature. > Intel LAM(linear Address Masking)[3 Charpter 14] supports similar feature with > the upper bits of pointers can be used as metadata, LAM support two modes: > LAM_U48:bits 48-62 can be used as metadata > LAM_U57:bits 57-62 can be used as metedata. > > These 2 patches mainly support those target hooks, but HWASAN is not really > enabled until the final decision for the LAM kernel interface which may take > quite a long time. We have verified our patches with a "fake" interface locally[4], and > decided to push the backend patches to the GCC13 to make other HWASAN developper's work > easy. Hello. A few random comments I noticed: 1) please document the new target -mlam in extend.texi 2) the description speaks about bits [48-62] or [57-62], can explain why the patch contains: + /* Mask off bit63 when LAM_U57. */ + if (ix86_lam_type == lam_u57) ? 3) Shouldn't the -lman option emit GNU_PROPERTY_X86_FEATURE_1_LAM_U57 or GNU_PROPERTY_X86_FEATURE_1_LAM_U48 .gnu.property note? 4) Can you please explain Florian's comment here: https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13#note_1181396487 Thanks, Martin > > [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html > [3] https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf > [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > Ok for trunk? > > liuhongt (2): > Implement hwasan target_hook. > Enable hwasan for x86-64. > > gcc/config/i386/i386-expand.cc | 12 ++++ > gcc/config/i386/i386-options.cc | 3 + > gcc/config/i386/i386-opts.h | 6 ++ > gcc/config/i386/i386-protos.h | 2 + > gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ > gcc/config/i386/i386.opt | 16 +++++ > libsanitizer/configure.tgt | 1 + > 7 files changed, 163 insertions(+) > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] Support HWASAN with Intel LAM 2022-11-28 14:40 ` Martin Liška @ 2022-11-29 2:10 ` H.J. Lu 2022-11-29 2:37 ` Hongtao Liu 1 sibling, 0 replies; 11+ messages in thread From: H.J. Lu @ 2022-11-29 2:10 UTC (permalink / raw) To: Martin Liška Cc: liuhongt, gcc-patches, crazylht, ubizjak, Florian Weimer On Mon, Nov 28, 2022 at 6:40 AM Martin Liška <mliska@suse.cz> wrote: > > On 11/11/22 02:26, liuhongt via Gcc-patches wrote: > > 2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several > > target hooks(Many thanks to their work) so other backends can do similar > > things if they have similar feature. > > Intel LAM(linear Address Masking)[3 Charpter 14] supports similar feature with > > the upper bits of pointers can be used as metadata, LAM support two modes: > > LAM_U48:bits 48-62 can be used as metadata > > LAM_U57:bits 57-62 can be used as metedata. > > > > These 2 patches mainly support those target hooks, but HWASAN is not really > > enabled until the final decision for the LAM kernel interface which may take > > quite a long time. We have verified our patches with a "fake" interface locally[4], and > > decided to push the backend patches to the GCC13 to make other HWASAN developper's work > > easy. > > Hello. > > A few random comments I noticed: > > 1) please document the new target -mlam in extend.texi > 2) the description speaks about bits [48-62] or [57-62], can explain why the patch contains: > > + /* Mask off bit63 when LAM_U57. */ > + if (ix86_lam_type == lam_u57) > ? > > 3) Shouldn't the -lman option emit GNU_PROPERTY_X86_FEATURE_1_LAM_U57 or GNU_PROPERTY_X86_FEATURE_1_LAM_U48 > .gnu.property note? Since there are no clear usages for these LAM bits, we can leave them out for now. > 4) Can you please explain Florian's comment here: > https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13#note_1181396487 > > Thanks, > Martin > > > > > [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > > [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html > > [3] https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf > > [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > > Ok for trunk? > > > > liuhongt (2): > > Implement hwasan target_hook. > > Enable hwasan for x86-64. > > > > gcc/config/i386/i386-expand.cc | 12 ++++ > > gcc/config/i386/i386-options.cc | 3 + > > gcc/config/i386/i386-opts.h | 6 ++ > > gcc/config/i386/i386-protos.h | 2 + > > gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ > > gcc/config/i386/i386.opt | 16 +++++ > > libsanitizer/configure.tgt | 1 + > > 7 files changed, 163 insertions(+) > > > -- H.J. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] Support HWASAN with Intel LAM 2022-11-28 14:40 ` Martin Liška 2022-11-29 2:10 ` H.J. Lu @ 2022-11-29 2:37 ` Hongtao Liu 2022-11-30 14:07 ` Martin Liška 1 sibling, 1 reply; 11+ messages in thread From: Hongtao Liu @ 2022-11-29 2:37 UTC (permalink / raw) To: Martin Liška Cc: liuhongt, gcc-patches, hjl.tools, ubizjak, Florian Weimer On Mon, Nov 28, 2022 at 10:40 PM Martin Liška <mliska@suse.cz> wrote: > > On 11/11/22 02:26, liuhongt via Gcc-patches wrote: > > 2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several > > target hooks(Many thanks to their work) so other backends can do similar > > things if they have similar feature. > > Intel LAM(linear Address Masking)[3 Charpter 14] supports similar feature with > > the upper bits of pointers can be used as metadata, LAM support two modes: > > LAM_U48:bits 48-62 can be used as metadata > > LAM_U57:bits 57-62 can be used as metedata. > > > > These 2 patches mainly support those target hooks, but HWASAN is not really > > enabled until the final decision for the LAM kernel interface which may take > > quite a long time. We have verified our patches with a "fake" interface locally[4], and > > decided to push the backend patches to the GCC13 to make other HWASAN developper's work > > easy. > > Hello. > > A few random comments I noticed: > > 1) please document the new target -mlam in extend.texi I will. > 2) the description speaks about bits [48-62] or [57-62], can explain why the patch contains: > Kernel will use bit 63 for special purposes, and here we want to extract the tag by shifting right the pointer 57 bits, and need to manually mask off bit63. > + /* Mask off bit63 when LAM_U57. */ > + if (ix86_lam_type == lam_u57) > ? > > 3) Shouldn't the -lman option emit GNU_PROPERTY_X86_FEATURE_1_LAM_U57 or GNU_PROPERTY_X86_FEATURE_1_LAM_U48 > .gnu.property note? > > 4) Can you please explain Florian's comment here: > https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13#note_1181396487 > > Thanks, > Martin > > > > > [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > > [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html > > [3] https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf > > [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > > Ok for trunk? > > > > liuhongt (2): > > Implement hwasan target_hook. > > Enable hwasan for x86-64. > > > > gcc/config/i386/i386-expand.cc | 12 ++++ > > gcc/config/i386/i386-options.cc | 3 + > > gcc/config/i386/i386-opts.h | 6 ++ > > gcc/config/i386/i386-protos.h | 2 + > > gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ > > gcc/config/i386/i386.opt | 16 +++++ > > libsanitizer/configure.tgt | 1 + > > 7 files changed, 163 insertions(+) > > > -- BR, Hongtao ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] Support HWASAN with Intel LAM 2022-11-29 2:37 ` Hongtao Liu @ 2022-11-30 14:07 ` Martin Liška 2022-12-09 2:04 ` Hongtao Liu 0 siblings, 1 reply; 11+ messages in thread From: Martin Liška @ 2022-11-30 14:07 UTC (permalink / raw) To: Hongtao Liu; +Cc: liuhongt, gcc-patches, hjl.tools, ubizjak, Florian Weimer On 11/29/22 03:37, Hongtao Liu wrote: > On Mon, Nov 28, 2022 at 10:40 PM Martin Liška <mliska@suse.cz> wrote: >> >> On 11/11/22 02:26, liuhongt via Gcc-patches wrote: >>> 2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several >>> target hooks(Many thanks to their work) so other backends can do similar >>> things if they have similar feature. >>> Intel LAM(linear Address Masking)[3 Charpter 14] supports similar feature with >>> the upper bits of pointers can be used as metadata, LAM support two modes: >>> LAM_U48:bits 48-62 can be used as metadata >>> LAM_U57:bits 57-62 can be used as metedata. >>> >>> These 2 patches mainly support those target hooks, but HWASAN is not really >>> enabled until the final decision for the LAM kernel interface which may take >>> quite a long time. We have verified our patches with a "fake" interface locally[4], and >>> decided to push the backend patches to the GCC13 to make other HWASAN developper's work >>> easy. >> >> Hello. >> >> A few random comments I noticed: >> >> 1) please document the new target -mlam in extend.texi > I will. Thanks. >> 2) the description speaks about bits [48-62] or [57-62], can explain why the patch contains: >> > Kernel will use bit 63 for special purposes, and here we want to > extract the tag by shifting right the pointer 57 bits, and need to > manually mask off bit63. And thanks for the explanation. Martin >> + /* Mask off bit63 when LAM_U57. */ >> + if (ix86_lam_type == lam_u57) >> ? >> >> 3) Shouldn't the -lman option emit GNU_PROPERTY_X86_FEATURE_1_LAM_U57 or GNU_PROPERTY_X86_FEATURE_1_LAM_U48 >> .gnu.property note? >> >> 4) Can you please explain Florian's comment here: >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13#note_1181396487 >> >> Thanks, >> Martin >> >>> >>> [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html >>> [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html >>> [3] https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf >>> [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master >>> >>> >>> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. >>> Ok for trunk? >>> >>> liuhongt (2): >>> Implement hwasan target_hook. >>> Enable hwasan for x86-64. >>> >>> gcc/config/i386/i386-expand.cc | 12 ++++ >>> gcc/config/i386/i386-options.cc | 3 + >>> gcc/config/i386/i386-opts.h | 6 ++ >>> gcc/config/i386/i386-protos.h | 2 + >>> gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ >>> gcc/config/i386/i386.opt | 16 +++++ >>> libsanitizer/configure.tgt | 1 + >>> 7 files changed, 163 insertions(+) >>> >> > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] Support HWASAN with Intel LAM 2022-11-30 14:07 ` Martin Liška @ 2022-12-09 2:04 ` Hongtao Liu 0 siblings, 0 replies; 11+ messages in thread From: Hongtao Liu @ 2022-12-09 2:04 UTC (permalink / raw) To: Martin Liška Cc: liuhongt, gcc-patches, hjl.tools, ubizjak, Florian Weimer On Wed, Nov 30, 2022 at 10:07 PM Martin Liška <mliska@suse.cz> wrote: > > On 11/29/22 03:37, Hongtao Liu wrote: > > On Mon, Nov 28, 2022 at 10:40 PM Martin Liška <mliska@suse.cz> wrote: > >> > >> On 11/11/22 02:26, liuhongt via Gcc-patches wrote: > >>> 2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several > >>> target hooks(Many thanks to their work) so other backends can do similar > >>> things if they have similar feature. > >>> Intel LAM(linear Address Masking)[3 Charpter 14] supports similar feature with > >>> the upper bits of pointers can be used as metadata, LAM support two modes: > >>> LAM_U48:bits 48-62 can be used as metadata > >>> LAM_U57:bits 57-62 can be used as metedata. > >>> > >>> These 2 patches mainly support those target hooks, but HWASAN is not really > >>> enabled until the final decision for the LAM kernel interface which may take > >>> quite a long time. We have verified our patches with a "fake" interface locally[4], and > >>> decided to push the backend patches to the GCC13 to make other HWASAN developper's work > >>> easy. I've committed 2 patches. > >> > >> Hello. > >> > >> A few random comments I noticed: > >> > >> 1) please document the new target -mlam in extend.texi > > I will. > > Thanks. > > >> 2) the description speaks about bits [48-62] or [57-62], can explain why the patch contains: > >> > > Kernel will use bit 63 for special purposes, and here we want to > > extract the tag by shifting right the pointer 57 bits, and need to > > manually mask off bit63. > > And thanks for the explanation. > > Martin > > >> + /* Mask off bit63 when LAM_U57. */ > >> + if (ix86_lam_type == lam_u57) > >> ? > >> > >> 3) Shouldn't the -lman option emit GNU_PROPERTY_X86_FEATURE_1_LAM_U57 or GNU_PROPERTY_X86_FEATURE_1_LAM_U48 > >> .gnu.property note? > >> > >> 4) Can you please explain Florian's comment here: > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13#note_1181396487 > >> > >> Thanks, > >> Martin > >> > >>> > >>> [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > >>> [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html > >>> [3] https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf > >>> [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master > >>> > >>> > >>> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > >>> Ok for trunk? > >>> > >>> liuhongt (2): > >>> Implement hwasan target_hook. > >>> Enable hwasan for x86-64. > >>> > >>> gcc/config/i386/i386-expand.cc | 12 ++++ > >>> gcc/config/i386/i386-options.cc | 3 + > >>> gcc/config/i386/i386-opts.h | 6 ++ > >>> gcc/config/i386/i386-protos.h | 2 + > >>> gcc/config/i386/i386.cc | 123 ++++++++++++++++++++++++++++++++ > >>> gcc/config/i386/i386.opt | 16 +++++ > >>> libsanitizer/configure.tgt | 1 + > >>> 7 files changed, 163 insertions(+) > >>> > >> > > > > > -- BR, Hongtao ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-12-09 2:04 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-11 1:26 [PATCH 0/2] Support HWASAN with Intel LAM liuhongt 2022-11-11 1:26 ` [PATCH 1/2] Implement hwasan target_hook liuhongt 2022-11-30 5:21 ` [PATCH 1/2 V2] " liuhongt 2022-11-11 1:26 ` [PATCH 2/2] Enable hwasan for x86-64 liuhongt 2022-11-28 3:35 ` [PATCH 0/2] Support HWASAN with Intel LAM Hongtao Liu 2022-11-28 7:12 ` Uros Bizjak 2022-11-28 14:40 ` Martin Liška 2022-11-29 2:10 ` H.J. Lu 2022-11-29 2:37 ` Hongtao Liu 2022-11-30 14:07 ` Martin Liška 2022-12-09 2:04 ` Hongtao Liu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).