Message ID | 20221111012631.76776-1-hongtao.liu@intel.com |
---|---|
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp475080wru; Thu, 10 Nov 2022 17:28:09 -0800 (PST) X-Google-Smtp-Source: AMsMyM6Fd1nTIVGeaF+pQ6spqsXNzFzKMrj85FBhKKHaXt+s8emJGKI9T82YedfIYL1QuCtgYxyc X-Received: by 2002:a50:cd16:0:b0:461:d5af:e9ea with SMTP id z22-20020a50cd16000000b00461d5afe9eamr3978994edi.403.1668130089327; Thu, 10 Nov 2022 17:28:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668130089; cv=none; d=google.com; s=arc-20160816; b=hYq/WzzA55DGT7pJX17GfKlyDwzSrE3ULCuVtwM3ZgYdaJymqGsUtz9WItuZXHlRei X+FBwN6lKFas3VSdTB/4XHgtmwK2kqBgP+4sBW6TOE+7BeWpHzlnQTYJe7l9SLpui3Lx l9/4eReScEgvEpGTI+5QE4akZmogtQgmDIdgzD9KnH5d5TmXr1ES0yXYwWfwL82qBN4V 1Dsg3A8t1ewESwM9xB96ftssR0/w/kNH04u68IjjEQDNtEMpI2RvobJ4PgmMCWlKkaKu J5mb85CW++dEmN/XTtr6DmwH7wqu2R7beue3H/O2J+mF9B3oRgEAAQ8wUcyneHDAHVUz 6v+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:message-id:date :subject:cc:to:dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=muHF1hkiaLmmGkj3NQPinp2WbJ0E3HQYRckLXYjAcP4=; b=0hRCUPGDquPi/drB7hFCr9MXeAzou/dHQAlXHihXI0/tsLGLRJeqG0QI0O8Wk3J/eI NWZKyGIrXUXK8zk0WaA52Ts+jBh6eb/EMdNYwrYWWv+YAhavKMk/HTOXvZJJZ/BlaS9U aI/RLLSMOPM36egkZEiMEpPYhK0A5ANwzJfxkhMEwhVurFz5oDHy3AndaWkAGgB/ph6X GMD9nqy8HJtEUgTwH4BIZKYYK9TLuDkIUseMv9S3jBkOcssLpisXV/0WLwf2TKMP4dc/ sgcuqKTr1vfAoJypYYu5U4N3urKk6f0mRGKrLr3bJ5LuRoW/V4o0dnnrwSeDS0zi84Cs EVUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=kGNhDuij; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id i15-20020a1709061e4f00b0073d6c0facdcsi609234ejj.259.2022.11.10.17.28.09 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Nov 2022 17:28:09 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=kGNhDuij; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8602E3836651 for <ouuuleilei@gmail.com>; Fri, 11 Nov 2022 01:27:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8602E3836651 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668130060; bh=muHF1hkiaLmmGkj3NQPinp2WbJ0E3HQYRckLXYjAcP4=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=kGNhDuij7u4VBph1uUQOnMOTa+O3rbXDKCEuvQ6aXlhz8FIrs47GR7I1l7UEXMjet nDkoo2AClwgrtMDNzvUN4oyytzaJx1HgrXyRjLih53f3FbSGZFdt63WsXEXNqz6URe Au3VCoqtbiz5VL4RjhRKYKLCcJtlTOkXojgqRuQk= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by sourceware.org (Postfix) with ESMTPS id ED91F3858D20 for <gcc-patches@gcc.gnu.org>; Fri, 11 Nov 2022 01:26:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED91F3858D20 X-IronPort-AV: E=McAfee;i="6500,9779,10527"; a="309117820" X-IronPort-AV: E=Sophos;i="5.96,155,1665471600"; d="scan'208";a="309117820" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2022 17:26:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10527"; a="762498212" X-IronPort-AV: E=Sophos;i="5.96,155,1665471600"; d="scan'208";a="762498212" Received: from shvmail03.sh.intel.com ([10.239.245.20]) by orsmga004.jf.intel.com with ESMTP; 10 Nov 2022 17:26:31 -0800 Received: from shliclel320.sh.intel.com (shliclel320.sh.intel.com [10.239.240.127]) by shvmail03.sh.intel.com (Postfix) with ESMTP id 39A0D100571B; Fri, 11 Nov 2022 09:26:31 +0800 (CST) To: gcc-patches@gcc.gnu.org Cc: crazylht@gmail.com, hjl.tools@gmail.com, ubizjak@gmail.com Subject: [PATCH 0/2] Support HWASAN with Intel LAM Date: Fri, 11 Nov 2022 09:26:29 +0800 Message-Id: <20221111012631.76776-1-hongtao.liu@intel.com> X-Mailer: git-send-email 2.18.1 X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: liuhongt via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: liuhongt <hongtao.liu@intel.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749161176687989350?= X-GMAIL-MSGID: =?utf-8?q?1749161176687989350?= |
Series |
Support HWASAN with Intel LAM
|
|
Message
liuhongt
Nov. 11, 2022, 1:26 a.m. UTC
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(+)
Comments
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 >
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.
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(+) >
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(+) > > >
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(+) > > >
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(+) >>> >> > >
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(+) > >>> > >> > > > > >