From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A0214C433F5 for ; Mon, 28 Feb 2022 07:52:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=v2Ydq8GN4Brj0SyOSQJYOdQwE95LOqdkt0UQT2CPXAE=; b=4DSsnDcwv7W250 HrsPOAsq35l6JL7cEUkWMgex43Qyz3iV5NKuDKVHyeXGUDVMzxP+PxaAM8YRSQz2HG52oNmUyVq6R DXsbAkzEHm5QM7NaHCFomi9d53PVqNKWnB9/Ssb1dRJyP998L0+w0IGq6oqM3lkupx/UrhbTTI0+k G4/P/YabMJMLdBPwpKhfC5KIWjOQcNzgc9mhlm/sTJjMia0JECSZAP1hdkNdQQcvwSEWJX+//m9cT Oq8ddHK25TsCePafGcItqsFqu1oDkeFoZotD1jsNCrlh2xuueG1DVhpcrpGsCEprQkRMQ7zEVfFDi ILV2bxOVgYJkEm7CHphA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOaoE-00B1YC-Bd; Mon, 28 Feb 2022 07:51:06 +0000 Received: from out30-56.freemail.mail.aliyun.com ([115.124.30.56]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOaoA-00B1X9-Vy for linux-arm-kernel@lists.infradead.org; Mon, 28 Feb 2022 07:51:04 +0000 X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R951e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04426; MF=ashimida@linux.alibaba.com; NM=1; PH=DS; RN=20; SR=0; TI=SMTPD_---0V5gZjsZ_1646034657; Received: from 192.168.193.153(mailfrom:ashimida@linux.alibaba.com fp:SMTPD_---0V5gZjsZ_1646034657) by smtp.aliyun-inc.com(127.0.0.1); Mon, 28 Feb 2022 15:50:58 +0800 Message-ID: <3389ef12-81c7-6aba-6c58-63e34008af0c@linux.alibaba.com> Date: Sun, 27 Feb 2022 23:50:57 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] [PATCH v2] AARCH64: Add gcc Shadow Call Stack support Content-Language: en-US To: Kees Cook Cc: catalin.marinas@arm.com, will@kernel.org, nathan@kernel.org, ndesaulniers@google.com, masahiroy@kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, mark.rutland@arm.com, samitolvanen@google.com, npiggin@gmail.com, linux@roeck-us.net, mhiramat@kernel.org, ojeda@kernel.org, luc.vanoostenryck@gmail.com, elver@google.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev, linux-hardening@vger.kernel.org References: <20220225032410.25622-1-ashimida@linux.alibaba.com> <202202251243.1E38256F9@keescook> From: Dan Li In-Reply-To: <202202251243.1E38256F9@keescook> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220227_235103_253136_7D8A310D X-CRM114-Status: GOOD ( 27.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/25/22 12:58, Kees Cook wrote: > On Thu, Feb 24, 2022 at 07:24:10PM -0800, Dan Li wrote: >> Signed-off-by: Dan Li > > Thanks for the tweaks! > >> --- >> FYI: >> This function can be used to test if the shadow call stack works: >> //noinline void __noscs scs_test(void) >> noinline void scs_test(void) >> { >> unsigned long * lr = (unsigned long *)__builtin_frame_address(0) + 1; >> >> asm volatile("str xzr, [%0]\n\t": : "r"(lr) : "x30"); >> } > > Not a big deal, but just FYI, there's a lot of whitespace trailing the > "}" above... > Ah, sorry for the mistake. >> >> If SCS protection is enabled, this function will return normally. >> If the function has __noscs attribute (scs disabled), it will crash due to 0 >> address access. > > It would be cool to turn this into an LKDTM test... (see things like the > CFI_FORWARD_PROTO test). I imagine this should be CFI_BACKWARD_SHADOW or > something... > OK, I'll add it in the next version. > Also, I assume you're using real hardware to test this? It'd be nice to > see if qemu can be convinced to run with the needed features. Whenever > I've tried this it becomes impossibly slow. :) > I also use qemu to test the patch (qemu 6.1.0 with command "-cpu max"), and can feel the performance drop. Maybe because my test environment only has simple busybox and ltp, the feeling of a slow system running is not that strong for me :) For comparison, I simply tested the difference in kernel boot time in my test environment: //run qemu with "-cpu cortex-a57", [ 1.254481] Run /linuxrc as init process //run qemu with "-cpu max" [ 3.566091] Run /linuxrc as init process >> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h >> index ccbbd31b3aae..deff5b308470 100644 >> --- a/include/linux/compiler-gcc.h >> +++ b/include/linux/compiler-gcc.h >> @@ -97,6 +97,10 @@ >> #define KASAN_ABI_VERSION 4 >> #endif >> >> +#ifdef CONFIG_SHADOW_CALL_STACK >> +#define __noscs __attribute__((__no_sanitize__("shadow-call-stack"))) >> +#endif > > I initially wondered if we need a separate __no_sanitize(STUFF) patch to > make the compiler-clang.h macros easier, but I see there are places > where we do multiple ("address", "hwaddress") and have specialized > macros, so I think this is fine. And since GCC doesn't support > "__has_feature", I think this is the correct location for this. > As in: https://lore.kernel.org/all/26a0a816-bc3e-2ac0-d773-0819d9f225af@linux.alibaba.com/ I think maybe we could use "#ifdef CONFIG_SHADOW_CALL_STACK" instead of "#if __has_attribute(__no_sanitize_address__)" here, then move it to `compiler_types.h`. From my current test results, __noscs seems to work fine in clang compilation. Thanks, Dan. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel