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