public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [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 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

* [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

* 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).