Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3264479pxm; Mon, 28 Feb 2022 15:58:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJyPsotSHMMKKOQxtM4D+oW9KFRWsVaBQLq4ql/KIiRCQ/ybohoXKIGcCFB7DG+ouxl7RUhK X-Received: by 2002:a05:6402:281:b0:40a:ad5d:217c with SMTP id l1-20020a056402028100b0040aad5d217cmr22084150edv.385.1646092735782; Mon, 28 Feb 2022 15:58:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646092735; cv=none; d=google.com; s=arc-20160816; b=rjBnpaoEh8xI3sBhfioub0uTiMDZouxRYMj8bZBXTD9fv5U3ui6TussQ2bBMVNgad1 Nue3yRBfDutGey3bvMc3/7dCo6R5HqKJ3GAvLBxgHaPKT82JKcQyccUWFSZ5t5hMlsKF VmD2vs06JP8qplg9AEgvR0PrlI9kma5d5Uc6UySn4tcYfKYOYn9UbSOIEhBU9KORvE/I xu0ZasVVjiDC0ngF2xLr0GWQcHhDXZ8gn+uJlv641RPVTTz1W+LVqoq3Up+MwDssriUC 5MOZJnhaRE9Y45CMCkjES4yKo2Z3MEx7x5A9pWcVBZvtQvz+LhQ/wgBWSKkT/muNahzX BCLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=hYlTdB/zH2zblgmoJbVMlgCNjIMCACNfbfxIFy7zCbg=; b=nhIvgxLBxr1b50q63GugIVwVEYS1IZv0ud0fe2hrlBDTA4xmhI/ajgBLuPaD0HTWGs oymX0ZDUjx+lp1rD9XQ/uvfPFqQ7yVkvtbOwBMPzUSFGFiLJ3Iqp3t/JLw1OMcOfAS1f 1BgjJPjGp0SwrC16Cgk18ODkVKYoFougxyQCReljkoMNwzTxCfNGhvWxFWhA0Rmy2Ovh 4tIfKtY+eNA1TcGfRiPiOFRktrJ72w30tZv44wQ67EKpwAlYsvNvFXjpFKrYjqayq0UM L9WVa8Ipprid9OEe6p+K3JfI2t/iupeteKdOQcny/J2eOK2NF8mr8VIPya6oQuU8G/Sg mcWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=YffGxEV3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o6-20020a170906974600b006d0fc0c1a3asi7682645ejy.817.2022.02.28.15.58.33; Mon, 28 Feb 2022 15:58:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=YffGxEV3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231474AbiB1WgI (ORCPT + 99 others); Mon, 28 Feb 2022 17:36:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229987AbiB1WgG (ORCPT ); Mon, 28 Feb 2022 17:36:06 -0500 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8B21113AD6 for ; Mon, 28 Feb 2022 14:35:25 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id u7so19399686ljk.13 for ; Mon, 28 Feb 2022 14:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hYlTdB/zH2zblgmoJbVMlgCNjIMCACNfbfxIFy7zCbg=; b=YffGxEV3fEqsY9GWBppaPKRNBrzynzAbY4wbDhUWFOco26tpAhO0IuRkhq7R7kVeGy kCGrfkmtISOexCpSwD56tAqw/AgM/E4KcPGmW07tdJ8L7KV9gUJ5loOsfwzPzx4rL0ff cDYHSDoIMX0sKc/h1HNr8rms3/UCLLdxaGBGd9OeWf0ChoSiL3vBeXsk8eFWuBftDU/a tP6qLXNC7TQPjB0FwnoMgHIzJtGjjBMHmv+TRyXjAHe2aDuPsMDDre44MqC1PK1dHv8X Xsj8hrFOHzN0ZmXDvsA1dh0jx7fSDdb/YL2BnjlgcDV9DxoY/cQJ3kyd2y/5n3Lfne1V V0xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hYlTdB/zH2zblgmoJbVMlgCNjIMCACNfbfxIFy7zCbg=; b=c1QQ6UkZuW6wi2K163llloWP7oN0wdrbc6jAbWlqzDilvs5Z4ElklpUVKHOLkQUL+Z 1QklXBli1/I3rlAhd2ChxuAaR7IivpaBpshTue976lIfutg8Hr0Wlxha+zJHgrNrrvh0 5l+CJx/H/IQGALYfY33nipWC7Q6oMwrRf2uEDOxIRElfbAzfsHc4i3cknrqMb7TmTg6J WOnClqEz48iX6OXPYojpOH3WmjplD4gWksZdsc9dfyat0fKYyp3hy/HSuRprlrGCthNr aYLBGFDt2XdZp8AINmiqL/I6EwDdWj/xN4FbiPTAUcPkDQDp/X6LxfjI8PpP8vKca/rh /k9Q== X-Gm-Message-State: AOAM5301ZfAIYDC1nE/u2CQVYJzOCmhO+WrtjehaBhGCFTfV73F86BH1 PnI0egPv9b7kJrIqASDaCE9ROYdSv4VKNUFRx7gQKw== X-Received: by 2002:a2e:bf24:0:b0:246:801e:39d3 with SMTP id c36-20020a2ebf24000000b00246801e39d3mr8691548ljr.472.1646087723877; Mon, 28 Feb 2022 14:35:23 -0800 (PST) MIME-Version: 1.0 References: <20220225032410.25622-1-ashimida@linux.alibaba.com> <26a0a816-bc3e-2ac0-d773-0819d9f225af@linux.alibaba.com> In-Reply-To: <26a0a816-bc3e-2ac0-d773-0819d9f225af@linux.alibaba.com> From: Nick Desaulniers Date: Mon, 28 Feb 2022 14:35:11 -0800 Message-ID: Subject: Re: [PATCH] [PATCH v2] AARCH64: Add gcc Shadow Call Stack support To: Dan Li Cc: Miguel Ojeda , Catalin Marinas , Will Deacon , Nathan Chancellor , Kees Cook , Masahiro Yamada , Thomas Gleixner , Andrew Morton , Mark Rutland , Sami Tolvanen , Nicholas Piggin , Guenter Roeck , Masami Hiramatsu , Miguel Ojeda , Luc Van Oostenryck , Marco Elver , linux-kernel , Linux ARM , llvm@lists.linux.dev, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-18.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 27, 2022 at 11:37 PM Dan Li wrote: > > > > On 2/25/22 12:47, Miguel Ojeda wrote: > > On Fri, Feb 25, 2022 at 4:24 AM Dan Li wrote: > >> > >> + - Clang (https://clang.llvm.org/docs/ShadowCallStack.html) > >> + - GCC (https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#Instrumentation-Options) > > > > Maybe Clang: and GCC: instead of the parenthesis? > > > Got it. > > >> +#ifdef CONFIG_SHADOW_CALL_STACK > >> +#define __noscs __attribute__((__no_sanitize__("shadow-call-stack"))) > >> +#endif > > > > Since both compilers have it, and I guess the `#ifdef` condition would > > work for both, could this be moved into `compiler_types.h` where the > > empty `__noscs` definition is, and remove the one from > > `compiler-clang.h`? > > > In the clang documentation I see __has_feature(shadow_call_stack) is > used to check if -fsanitize=shadow-call-stack is enabled, so I think > maybe it's fine to use "#ifdef CONFIG_SHADOW_CALL_STACK" > instead of "#if __has_attribute(__no_sanitize_address__)" here, then > move it to `compiler_types.h`. Or simply add a #define for __noscs to include/linux/compiler-gcc.h with appropriate guard and leave the existing #ifndef in include/linux/compiler_types.h as is. I'd prefer that when the compilers differ in terms of feature detection since it's as explicit as possible. > > And from the results of my local clang 12 compilation, this doesn't > seem to be a problem. > > Link: https://clang.llvm.org/docs/ShadowCallStack.html#has-feature-shadow-call-stack -- Thanks, ~Nick Desaulniers