Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1613324ybh; Tue, 14 Jul 2020 02:33:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx6ggd9ceMT/jq1a9qVqNX0SI7MmYZaH8ibcrw7LprKwieZIx3mso2NskMbju02ermKNaGI X-Received: by 2002:a17:906:1111:: with SMTP id h17mr3546533eja.203.1594719217748; Tue, 14 Jul 2020 02:33:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594719217; cv=none; d=google.com; s=arc-20160816; b=FDcej1AcBZ+oDz2/sAxQ2Nu9pvwI/1VC+vt3TPfYOk01eHNFbXh43tVWximfj2/473 dqfCsvkliPHUv4RraNcITfkqyW6GPoFT6FLcNOkK6+34XOGWXiOzBi6naMshTF0dtKl9 JuoD1hc5P9PZ+8AzJTJ5NeN5jY96lzHjj//rYSiifjsWAXlg7j4JGAeMWJHzAydzet4M KNijszKTpkWDVZUdxJwdRZEbquFnzZjI+e58rL5pwA77V8TpQECRoD4ODxdaim8HF7jU 7cUJJNDB3EKrb601V1WSzD6W32dXusrES8ZjJa2PHcNUtjsdeiv0YxKIY2qoGtiwqXWu VyHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=XrMY5oT21V+ZW/I1jm+ULHI1IZRIIyEVck5D0WelQ80=; b=KZhV8LZWOKIqxeYs6KoWW0/9Q33IUKt0fceI8o1JXoFpD9mKktT8BnSnLQrO0IUgcC rX6/XOhA4cV6cCjSCN2vKfBEEGukVbydnOESyiamTKKOcuD6pE7qpqBOzdK7B3cHp3JP vOyhU/ubAlyIuWIKPuWG5PzGnkaId9FYf5X3NYDQttuDbWasD4IFcok/MI58l2iYZa/N pXhCjpGGrMlY0V4LwqDr1hEEqQjgMVcPKl2CpVjYa2e/lGnl1nI1bBOm87EIJthsZoaG 176+HREKjsRh8WBoGXmTV3QL+o36o4LNZM5RF0vgDcRtKCvKZzYnn2JUF0DjXEeE0tss /EiA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o21si9685284ejg.550.2020.07.14.02.33.15; Tue, 14 Jul 2020 02:33:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726748AbgGNJcv (ORCPT + 99 others); Tue, 14 Jul 2020 05:32:51 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:59548 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725952AbgGNJcv (ORCPT ); Tue, 14 Jul 2020 05:32:51 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01f04427;MF=guoren@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0U2i6OKl_1594719159; Received: from IT-C02Z45M7LVCF.local(mailfrom:guoren@linux.alibaba.com fp:SMTPD_---0U2i6OKl_1594719159) by smtp.aliyun-inc.com(127.0.0.1); Tue, 14 Jul 2020 17:32:39 +0800 Subject: Re: [PATCH] arm64: Make TSK_STACK_CANARY more accurate defined To: Will Deacon , guoren@kernel.org Cc: catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org References: <1594613013-13059-1-git-send-email-guoren@kernel.org> <20200714083715.GE4516@willie-the-truck> From: Guo Ren Message-ID: Date: Tue, 14 Jul 2020 17:32:39 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200714083715.GE4516@willie-the-truck> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/7/14 下午4:37, Will Deacon wrote: > On Mon, Jul 13, 2020 at 04:03:33AM +0000, guoren@kernel.org wrote: >> From: Guo Ren >> >> TSK_STACK_CANARY only used in arm64/Makefile with >> CONFIG_STACKPROTECTOR_PER_TASK wrap. So use the same policy in >> asm-offset.c. >> >> Signed-off-by: Guo Ren >> Co-developed-by: Kees Cook >> Cc: Catalin Marinas >> Cc: Will Deacon >> --- >> arch/arm64/kernel/asm-offsets.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c >> index 0577e21..37d5d3d 100644 >> --- a/arch/arm64/kernel/asm-offsets.c >> +++ b/arch/arm64/kernel/asm-offsets.c >> @@ -39,7 +39,7 @@ int main(void) >> DEFINE(TSK_TI_SCS_SP, offsetof(struct task_struct, thread_info.scs_sp)); >> #endif >> DEFINE(TSK_STACK, offsetof(struct task_struct, stack)); >> -#ifdef CONFIG_STACKPROTECTOR >> +#ifdef CONFIG_STACKPROTECTOR_PER_TASK >> DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary)); >> #endif > I don't think this really makese much sense. The 'stack_canary' field in > 'struct task_struct' is defined as: > > #ifdef CONFIG_STACKPROTECTOR > /* Canary value for the -fstack-protector GCC feature: */ > unsigned long stack_canary; > #endif > > so I think it makes sense to follow that in asm-offsets.c > > Does the current code actually cause a problem? No, I just want to know how arm64 reply, ref: https://lore.kernel.org/linux-riscv/1594397998-10221-1-git-send-email-guoren@kernel.org/T/#t Best Regards  Guo Ren