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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 3D681C4CECC for ; Mon, 27 Apr 2020 17:39:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 106AF20B1F for ; Mon, 27 Apr 2020 17:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588009182; bh=hrpwDQjnNosOZuDVeZVm9aVGNZZMloN7/cGIPwaOS2E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=RqupOWb92FVOG4MKKNn93c7fjG5k249z+gxsgZVLjTJPeJMfNfsbvH5PPpPtOWPAB 9y34TL01pQ8aOT+woHtbJbh08e+5khl5EeeIk5oaO46zVBr1VXBr6nGeZo0ztPsQxf Kkv7gekDs3kolQS0AzGrPD7dqUQx4m+pnhLOgx64= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726348AbgD0Rjl (ORCPT ); Mon, 27 Apr 2020 13:39:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:49348 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726238AbgD0Rjk (ORCPT ); Mon, 27 Apr 2020 13:39:40 -0400 Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (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 0D0B6215A4 for ; Mon, 27 Apr 2020 17:39:40 +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-f41.google.com with SMTP id f3so19820574ioj.1 for ; Mon, 27 Apr 2020 10:39:40 -0700 (PDT) X-Gm-Message-State: AGi0PuabKIDMbKlvbS6NeOP6nzB8VKFk4DeJfGmF/TvLJFnfy5II5+U3 qyWyeGdfmCEVpUE+Z6MJw/DPsiojPdkqeLlhKRc= 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 Cc: Will Deacon , Catalin Marinas , James Morse , Steven Rostedt , Ard Biesheuvel , Mark Rutland , Masahiro Yamada , Michal Marek , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Kees Cook , Jann Horn , Marc Zyngier , kernel-hardening@lists.openwall.com, Nick Desaulniers , Linux Kernel Mailing List , Miguel Ojeda , Masami Hiramatsu , clang-built-linux , Laura Abbott , Dave Martin , Linux ARM 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 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.