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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66268C3F2CD for ; Fri, 28 Feb 2020 20:51:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3BA222469F for ; Fri, 28 Feb 2020 20:51:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WsM/fb6y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726490AbgB1UvW (ORCPT ); Fri, 28 Feb 2020 15:51:22 -0500 Received: from mail-vs1-f68.google.com ([209.85.217.68]:35051 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725805AbgB1UvW (ORCPT ); Fri, 28 Feb 2020 15:51:22 -0500 Received: by mail-vs1-f68.google.com with SMTP id u26so2845717vsg.2 for ; Fri, 28 Feb 2020 12:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SitQuWaYJYljvcCrYj4fkHHkPc4o0vcrOMkYmOvH+dg=; b=WsM/fb6y5CGtFjZacOBZZYlUzkSwNVN+lgzwRpeO7kE0e/83uZ2+K3ZTNKkv0Q8dSI a+Cugxv8TY/rUcQjCqy8r8gHFh1GeAOUAEhTpt/68gti4/raIjNU9nV6YsuYTnE1pQg4 BjR09FkgavjN4CagxM8NdJbh77wJU1R5zT8YKoCpeYzhTXcpH67QL/XNAng5pvrnCqzW IlpTQwrR9LWfOP5fofMezihxVEIAGD6q+96J1skrj6gfpRAHBApVND96QkQOppRbBXCs AIgan+ocDu8aj28mHw/t5DZ9jenFbfBChKOdPnSbMKWlknHeyCJ9J8SDvVmB2tsmDd2F ZnZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SitQuWaYJYljvcCrYj4fkHHkPc4o0vcrOMkYmOvH+dg=; b=o9pUW2Tr4b1b4bPCz0kl/oOBavj6vWWUqKBrjkjNQOnJTFz1Dj4HX/bHa5oyu/QRbN hAgkqHxl6vVxL2+sFHZGIESTP1nPE0Zl30LAzilJf39jnwSZNWb6Xm+fZ17AEuevK4s4 FhPBen/qZOfD9ZNOddrW9YH2f/s2HB+4R+TahHw4neEfaayBpD9b9U2LOA/EoCIhlmmU dlIRREopjBJBW1fWilZHLOEHcHQyqMLmN+Os6/TYivJDXpbY9Z6b6ElFbPjnUTkDxosu o/OBcYML/TTYVMO6JtQ5r3SaLPTuTQFO1z/qXZNZlv5yG8IGttJyvgXOV8QXu4LWyTP5 LYEQ== X-Gm-Message-State: ANhLgQ1ngeqwQFtdZVKap/o7G7b85pMyn3Mri9hhnI6G14XXRO/xzhyE JrsQe5l5ZlBi3Ojf5h3EnzyK910kwDe3HWwY/PfqRQ== X-Google-Smtp-Source: ADFU+vvQxOaGGrHRtQqNZNl73QRM6vi1YBVrsU8i6+lpeaELnBsJ5FIiG7kODI7N1KIXUtRDUGM7/idkISnluUIb4h8= X-Received: by 2002:a67:fb8d:: with SMTP id n13mr309624vsr.15.1582923080404; Fri, 28 Feb 2020 12:51:20 -0800 (PST) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20200225173933.74818-1-samitolvanen@google.com> <20200225173933.74818-11-samitolvanen@google.com> <56b82a54-044a-75ec-64e5-6ba25b19571f@arm.com> In-Reply-To: <56b82a54-044a-75ec-64e5-6ba25b19571f@arm.com> From: Sami Tolvanen Date: Fri, 28 Feb 2020 12:51:09 -0800 Message-ID: Subject: Re: [PATCH v9 10/12] arm64: implement Shadow Call Stack To: James Morse Cc: Will Deacon , Catalin Marinas , Steven Rostedt , Masami Hiramatsu , Ard Biesheuvel , Mark Rutland , Dave Martin , Kees Cook , Laura Abbott , Marc Zyngier , Nick Desaulniers , Jann Horn , Miguel Ojeda , Masahiro Yamada , clang-built-linux , Kernel Hardening , linux-arm-kernel , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 28, 2020 at 8:31 AM James Morse wrote: > > +#ifndef __ASSEMBLY__ > > As the whole file is guarded by this, why do you need to include it in assembly files at all? True, the include in head.S is not needed. I'll remove it in the next version. > > +static inline void scs_overflow_check(struct task_struct *tsk) > > +{ > > + if (unlikely(scs_corrupted(tsk))) > > + panic("corrupted shadow stack detected inside scheduler\n"); > > Could this ever catch anything with CONFIG_SHADOW_CALL_STACK_VMAP? > Wouldn't we have hit the vmalloc guard page at the point of overflow? With CONFIG_SHADOW_CALL_STACK_VMAP, even though we allocate a full page, SCS_SIZE is still 1k, so we should catch overflows here well before we hit the guard page. > It would be nice to have a per-cpu stack that we switch to when on the overflow stack. It shouldn't be a problem to add an overflow shadow stack if you think one is needed. > I can't work out why this needs to be before before idle_task_exit()... > It needs to run before init_idle(), which calls scs_task_reset(), but all that is on the > cpu_up() path. (if it is to pair those up, any reason core code can't do both?) At this point, the idle task's shadow stack pointer is only stored in x18, so we need to save it again to thread_info before the CPU shuts down, or we'll lose the pointer. Sami 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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8614AC3F2D2 for ; Fri, 28 Feb 2020 20:51:27 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 542DE2469F for ; Fri, 28 Feb 2020 20:51:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="J9agaQwl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="WsM/fb6y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 542DE2469F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QIshK+hEPP4bjP+Sk9o8bisFJOJdb57AzbcrqO9MInY=; b=J9agaQwlqxSY+i SrkgdWW/udGGw+1cN5EBl1gy7AKD7QqimJQmTBkqOF+tUeqtraLvhY6nk0kein8Qmy8nLve9Yxqgn FVfK1d6+o+iOfUKmtbdzJHJedmhfPbCgzNjoXm8rmICnAU5gwUeCRxt4Mkie6i3bYxjP9CGnaVZPS DTcuUa3+kO12cX1A9l9Yk9rgRrl+VR2VqQ87KSjcFPHeL30aUu9S6RPH+1eAtfklPO6MTmWPbb6Xp t8nCtG+fO2Bce4SXOmPAKp9qihu3d/vhreyJZ9sBejxUTXqwJWtq2fG56KgExJWzStBIqNAUrEeAX DscuvQwtjcqaJ6vx3qvA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j7mbW-0000lX-OU; Fri, 28 Feb 2020 20:51:26 +0000 Received: from mail-vs1-xe44.google.com ([2607:f8b0:4864:20::e44]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j7mbT-0000kr-BC for linux-arm-kernel@lists.infradead.org; Fri, 28 Feb 2020 20:51:24 +0000 Received: by mail-vs1-xe44.google.com with SMTP id c18so2821412vsq.7 for ; Fri, 28 Feb 2020 12:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SitQuWaYJYljvcCrYj4fkHHkPc4o0vcrOMkYmOvH+dg=; b=WsM/fb6y5CGtFjZacOBZZYlUzkSwNVN+lgzwRpeO7kE0e/83uZ2+K3ZTNKkv0Q8dSI a+Cugxv8TY/rUcQjCqy8r8gHFh1GeAOUAEhTpt/68gti4/raIjNU9nV6YsuYTnE1pQg4 BjR09FkgavjN4CagxM8NdJbh77wJU1R5zT8YKoCpeYzhTXcpH67QL/XNAng5pvrnCqzW IlpTQwrR9LWfOP5fofMezihxVEIAGD6q+96J1skrj6gfpRAHBApVND96QkQOppRbBXCs AIgan+ocDu8aj28mHw/t5DZ9jenFbfBChKOdPnSbMKWlknHeyCJ9J8SDvVmB2tsmDd2F ZnZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SitQuWaYJYljvcCrYj4fkHHkPc4o0vcrOMkYmOvH+dg=; b=eQe0O5UiL0KNwtbROi4SF/xmPR9PF0qVpcVPG+mvaIihqUjlhB8Vu82MtXPpDZGPpW O8eP016+stLvssoZ6b0iBHgEhvLzCFords226c75HH6qR92tGY5pR410pNsfipujDB3D 0dJlwz9lwtMbzEomgC0Y2xH60JAMeSiWtJc1FwyDLk151/bEYQ0ED8wx3w/4hn6a9zvA D71PFeKTst5mQJT2yRG7KMrHhcLFAPJ5evqpkCKtg2ip3dS23VbgdUQnuSRyUnKFH+Qe zraO4jq+xTCWHUw9tBdHui1DUg32JXaaHVntemgU4g5JmcmDp8D3TUBdMRf+rA++aIrF hevQ== X-Gm-Message-State: ANhLgQ1f4pSK1q9HwlQaxvCr+gnUs5H3fNebjyct/ndgpGSvCBBD2z07 qtiHXSUIwUnbQ8pN8NhIX1GT2aBwHMc/BCMlWeqQAQ== X-Google-Smtp-Source: ADFU+vvQxOaGGrHRtQqNZNl73QRM6vi1YBVrsU8i6+lpeaELnBsJ5FIiG7kODI7N1KIXUtRDUGM7/idkISnluUIb4h8= X-Received: by 2002:a67:fb8d:: with SMTP id n13mr309624vsr.15.1582923080404; Fri, 28 Feb 2020 12:51:20 -0800 (PST) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20200225173933.74818-1-samitolvanen@google.com> <20200225173933.74818-11-samitolvanen@google.com> <56b82a54-044a-75ec-64e5-6ba25b19571f@arm.com> In-Reply-To: <56b82a54-044a-75ec-64e5-6ba25b19571f@arm.com> From: Sami Tolvanen Date: Fri, 28 Feb 2020 12:51:09 -0800 Message-ID: Subject: Re: [PATCH v9 10/12] arm64: implement Shadow Call Stack To: James Morse X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200228_125123_409072_CD08A679 X-CRM114-Status: GOOD ( 14.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Kees Cook , Ard Biesheuvel , Masahiro Yamada , Catalin Marinas , Jann Horn , Nick Desaulniers , LKML , Steven Rostedt , Miguel Ojeda , clang-built-linux , Masami Hiramatsu , Marc Zyngier , Kernel Hardening , Laura Abbott , Will Deacon , Dave Martin , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Feb 28, 2020 at 8:31 AM James Morse wrote: > > +#ifndef __ASSEMBLY__ > > As the whole file is guarded by this, why do you need to include it in assembly files at all? True, the include in head.S is not needed. I'll remove it in the next version. > > +static inline void scs_overflow_check(struct task_struct *tsk) > > +{ > > + if (unlikely(scs_corrupted(tsk))) > > + panic("corrupted shadow stack detected inside scheduler\n"); > > Could this ever catch anything with CONFIG_SHADOW_CALL_STACK_VMAP? > Wouldn't we have hit the vmalloc guard page at the point of overflow? With CONFIG_SHADOW_CALL_STACK_VMAP, even though we allocate a full page, SCS_SIZE is still 1k, so we should catch overflows here well before we hit the guard page. > It would be nice to have a per-cpu stack that we switch to when on the overflow stack. It shouldn't be a problem to add an overflow shadow stack if you think one is needed. > I can't work out why this needs to be before before idle_task_exit()... > It needs to run before init_idle(), which calls scs_task_reset(), but all that is on the > cpu_up() path. (if it is to pair those up, any reason core code can't do both?) At this point, the idle task's shadow stack pointer is only stored in x18, so we need to save it again to thread_info before the CPU shuts down, or we'll lose the pointer. Sami _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AD20C3F2CD for ; Fri, 28 Feb 2020 20:51:41 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id CCA062469F for ; Fri, 28 Feb 2020 20:51:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WsM/fb6y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCA062469F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-18015-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 30186 invoked by uid 550); 28 Feb 2020 20:51:33 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 30166 invoked from network); 28 Feb 2020 20:51:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SitQuWaYJYljvcCrYj4fkHHkPc4o0vcrOMkYmOvH+dg=; b=WsM/fb6y5CGtFjZacOBZZYlUzkSwNVN+lgzwRpeO7kE0e/83uZ2+K3ZTNKkv0Q8dSI a+Cugxv8TY/rUcQjCqy8r8gHFh1GeAOUAEhTpt/68gti4/raIjNU9nV6YsuYTnE1pQg4 BjR09FkgavjN4CagxM8NdJbh77wJU1R5zT8YKoCpeYzhTXcpH67QL/XNAng5pvrnCqzW IlpTQwrR9LWfOP5fofMezihxVEIAGD6q+96J1skrj6gfpRAHBApVND96QkQOppRbBXCs AIgan+ocDu8aj28mHw/t5DZ9jenFbfBChKOdPnSbMKWlknHeyCJ9J8SDvVmB2tsmDd2F ZnZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SitQuWaYJYljvcCrYj4fkHHkPc4o0vcrOMkYmOvH+dg=; b=ZYe04Ad43yjKSVAB2oFvlL3xycd038xBqB2TXX1uiqmLMSM8TMaNvWfu4sDwBDfHTK 0iHh+A2IlF8q85Szp/yjyVgwcqa4qcInc2DW+Wrz1ktoKPraDorwqlNxIxAZp2S05sv/ hT+ii2laLBl15bvopo2Pu1pUwvaFlfP8DckusjVHEOGe39/0yUTdH3z6hopjpC+cgcFP LlLygdJdmPpLEmG9GtpDymX3SstptoqtBXLTOpBL2kZQmLpfiuurDfaTI6/XfKUcs9nc 2/Zxw5+uSi5ai4yYih5ZnTtRmwuGtzLHY9mVb+WAdGq2UG+uDWyt4T5YAwPsDUOblbG8 YsyA== X-Gm-Message-State: ANhLgQ0JC3Ye/Twd0cSNi3YL7PUIB0dxHLFkC9zJySRtYKQmfC7qe6nl LJjXKWtidBhY3PusKNWowf9SfgZM9lsWSLjb5kfaOg== X-Google-Smtp-Source: ADFU+vvQxOaGGrHRtQqNZNl73QRM6vi1YBVrsU8i6+lpeaELnBsJ5FIiG7kODI7N1KIXUtRDUGM7/idkISnluUIb4h8= X-Received: by 2002:a67:fb8d:: with SMTP id n13mr309624vsr.15.1582923080404; Fri, 28 Feb 2020 12:51:20 -0800 (PST) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20200225173933.74818-1-samitolvanen@google.com> <20200225173933.74818-11-samitolvanen@google.com> <56b82a54-044a-75ec-64e5-6ba25b19571f@arm.com> In-Reply-To: <56b82a54-044a-75ec-64e5-6ba25b19571f@arm.com> From: Sami Tolvanen Date: Fri, 28 Feb 2020 12:51:09 -0800 Message-ID: Subject: Re: [PATCH v9 10/12] arm64: implement Shadow Call Stack To: James Morse Cc: Will Deacon , Catalin Marinas , Steven Rostedt , Masami Hiramatsu , Ard Biesheuvel , Mark Rutland , Dave Martin , Kees Cook , Laura Abbott , Marc Zyngier , Nick Desaulniers , Jann Horn , Miguel Ojeda , Masahiro Yamada , clang-built-linux , Kernel Hardening , linux-arm-kernel , LKML Content-Type: text/plain; charset="UTF-8" On Fri, Feb 28, 2020 at 8:31 AM James Morse wrote: > > +#ifndef __ASSEMBLY__ > > As the whole file is guarded by this, why do you need to include it in assembly files at all? True, the include in head.S is not needed. I'll remove it in the next version. > > +static inline void scs_overflow_check(struct task_struct *tsk) > > +{ > > + if (unlikely(scs_corrupted(tsk))) > > + panic("corrupted shadow stack detected inside scheduler\n"); > > Could this ever catch anything with CONFIG_SHADOW_CALL_STACK_VMAP? > Wouldn't we have hit the vmalloc guard page at the point of overflow? With CONFIG_SHADOW_CALL_STACK_VMAP, even though we allocate a full page, SCS_SIZE is still 1k, so we should catch overflows here well before we hit the guard page. > It would be nice to have a per-cpu stack that we switch to when on the overflow stack. It shouldn't be a problem to add an overflow shadow stack if you think one is needed. > I can't work out why this needs to be before before idle_task_exit()... > It needs to run before init_idle(), which calls scs_task_reset(), but all that is on the > cpu_up() path. (if it is to pair those up, any reason core code can't do both?) At this point, the idle task's shadow stack pointer is only stored in x18, so we need to save it again to thread_info before the CPU shuts down, or we'll lose the pointer. Sami