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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 C622FC4CECD for ; Mon, 27 Apr 2020 17:39:46 +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 7782C2078E for ; Mon, 27 Apr 2020 17:39:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="U4d6f1u3"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="OEG6mbnA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7782C2078E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=1sdjUpc8/jABCRF25B5vxAY4uNKVitQIjExCmhfKrbk=; b=U4d6f1u3wGgnxW IHylY7+mmFrM0V3NZs7qkHNr9ncytJUDNFO8uxMuoWewu8xGsvGvl/4OwGkC/EelkyUzvHM8z8WGE ANaM1QpeuFHckqLNM9eU7b60hLUxyfHYySGbYBfVTiE0/KLA0e1D+5Zi2n4DysHrMVp/NTLiXDKtY sAGTiI2YLoYxThQIP8SY8sSh7yB37aHXtR75JBUWK0O71aBdSg0JiAZ+ORPnPQTY1bMReGW35zXoY FxTu/vuqw59VvK4gSzYIY4q9Xms1OjVuEOKcFLj/1rUYnvKWmChgydPWXb/WRwR3v5BWkZftK76v4 BZhCD6HGcCiX5HY6GXEQ==; 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 1jT7jM-0006Nu-QD; Mon, 27 Apr 2020 17:39:44 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jT7jJ-0006Md-Ke for linux-arm-kernel@lists.infradead.org; Mon, 27 Apr 2020 17:39:43 +0000 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E74002078C for ; Mon, 27 Apr 2020 17:39:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588009180; bh=hrpwDQjnNosOZuDVeZVm9aVGNZZMloN7/cGIPwaOS2E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OEG6mbnAPk9Yk6G26yTR/TVVBKEZvPHXDTXfYgvruVQNacNQiflszdd+0GVvZRYy2 rHV46TRK4sOsK5sEMulbd30Ou3kNNmzHcQfrDJhyprXiLmr6/v0Azt6qbGniF3D4Qm mpIkDvC4ZJOa4fBih6gCRXDIAHa8Yz36RoEypDhA= Received: by mail-io1-f48.google.com with SMTP id w4so19735122ioc.6 for ; Mon, 27 Apr 2020 10:39:39 -0700 (PDT) X-Gm-Message-State: AGi0PubmUrgS6heZMXzcTMP3TtTBpNvl5rENg9Zi0imoXwyqVSaYsB5A Nh5TQw6KK382U3SAC1rirAJHPSszDqru0uVEblM= X-Google-Smtp-Source: APiQypKwgbBJU8vwKjnBG/W2/hGRkTtjHMSQFFtwdBypUd4jq0xAuehjbqPR+7Prha81wkO7jJ+QOnSaEJO928BJk1c= X-Received: by 2002:a6b:5904:: with SMTP id n4mr22515735iob.142.1588009179242; Mon, 27 Apr 2020 10:39:39 -0700 (PDT) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20200427160018.243569-1-samitolvanen@google.com> In-Reply-To: <20200427160018.243569-1-samitolvanen@google.com> From: Ard Biesheuvel Date: Mon, 27 Apr 2020 19:39:28 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v13 00/12] add support for Clang's Shadow Call Stack To: Sami Tolvanen X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200427_103941_716302_F97383B4 X-CRM114-Status: GOOD ( 24.22 ) 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 , Juri Lelli , kernel-hardening@lists.openwall.com, Peter Zijlstra , Catalin Marinas , Will Deacon , Marc Zyngier , Masahiro Yamada , clang-built-linux , Ingo Molnar , Laura Abbott , Dave Martin , Kees Cook , Jann Horn , Steven Rostedt , Linux ARM , Michal Marek , Ard Biesheuvel , Nick Desaulniers , Linux Kernel Mailing List , Miguel Ojeda , James Morse , Masami Hiramatsu 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 Mon, 27 Apr 2020 at 18:00, Sami Tolvanen wrote: > > This patch series adds support for Clang's Shadow Call Stack > (SCS) mitigation, which uses a separately allocated shadow stack > to protect against return address overwrites. More information > can be found here: > > https://clang.llvm.org/docs/ShadowCallStack.html > > SCS provides better protection against traditional buffer > overflows than CONFIG_STACKPROTECTOR_*, but it should be noted > that SCS security guarantees in the kernel differ from the ones > documented for user space. The kernel must store addresses of > shadow stacks in memory, which means an attacker capable of > reading and writing arbitrary memory may be able to locate them > and hijack control flow by modifying the shadow stacks. > > SCS is currently supported only on arm64, where the compiler > requires the x18 register to be reserved for holding the current > task's shadow stack pointer. > > With -fsanitize=shadow-call-stack, the compiler injects > instructions to all non-leaf C functions to store the return > address to the shadow stack, and unconditionally load it again > before returning. As a result, SCS is incompatible with features > that rely on modifying function return addresses in the kernel > stack to alter control flow. A copy of the return address is > still kept in the kernel stack for compatibility with stack > unwinding, for example. > > SCS has a minimal performance overhead, but allocating > shadow stacks increases kernel memory usage. The feature is > therefore mostly useful on hardware that lacks support for PAC > instructions. > > Changes in v13: > - Changed thread_info::shadow_call_stack to a base address and > an offset instead, and removed the now unneeded __scs_base() > and scs_save(). > - Removed alignment from the kmem_cache and static allocations. > - Removed the task_set_scs() helper function. > - Moved the assembly code for loading and storing the offset in > thread_info to scs_load/save macros. > - Added offset checking to scs_corrupted(). > - Switched to cmpxchg_relaxed() in scs_check_usage(). > OK, so one thing that came up in an offline discussion about SCS is the way it interacts with the vmap'ed stack. The vmap'ed stack is great for robustness, but it only works if things don't explode for other reasons in the mean time. This means the ordinary-to-shadow-call-stack size ratio should be chosen such that it is *really* unlikely you could ever overflow the shadow call stack and corrupt another task's call stack before hitting the vmap stack's guard region. Alternatively, I wonder if there is a way we could let the SCS and ordinary stack share the [bottom of] the vmap'ed region. That would give rather nasty results if the ordinary stack overflows into the SCS, but for cases where we really recurse out of control, we could catch this occurrence on either stack, whichever one occurs first. And the nastiness -when it does occur- will not corrupt any state beyond the stack of the current task. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel