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,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 08673CA9EA9 for ; Fri, 18 Oct 2019 17:18:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CE81D21D7C for ; Fri, 18 Oct 2019 17:18:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vsQmN/Ap" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2502024AbfJRRSx (ORCPT ); Fri, 18 Oct 2019 13:18:53 -0400 Received: from mail-ua1-f67.google.com ([209.85.222.67]:41963 "EHLO mail-ua1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405285AbfJRRSx (ORCPT ); Fri, 18 Oct 2019 13:18:53 -0400 Received: by mail-ua1-f67.google.com with SMTP id l13so1934180uap.8 for ; Fri, 18 Oct 2019 10:18:52 -0700 (PDT) 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=0HIzf5D0wGbvpmxHvIyOvn+49UWE2lHPyTZCg3y02sw=; b=vsQmN/ApjkODa5g1BT612x/4GGL20gZVZE8EGaFhwsXbdCcFD/fycGlyho4gxOJTFH UNt9ub/I4P/h809X5D4yAx7rCwQfs1BEVFWXiVYtxsoUMxjlzIEJPcfVyB8tF344B2aC FjFd1SH8THaH/Pw81yxXP9FQn01T7I+/YsrNyL9mssL2T1CuwuFiQluKl0/fFUrg4HLq GlWt1dVIFhyf7eCqu7QIp5RVLWS2ZUOsoD7wzE3W1jtwUAY4NHDTbaS0+XPgu0S1K6/l VhJ5hk4oAgFzg9fAGqgifT4d4FsvndIJvJc42Q3EHtKExcLFN4z8Qliw6bt6wkdvd8lR FnJw== 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=0HIzf5D0wGbvpmxHvIyOvn+49UWE2lHPyTZCg3y02sw=; b=o5nY9p2w78LdFZgHE0oRQg52v3gaiPGxgV8bns1BX+IVs9gdwo3l3jD07/iKzc0BGS +e9VMLmmfaVBpQS7eTMU9L1dZ8GqJnB5eTt/eYouiNTj57DInjiM12b6Rkm3u2mzd7hu D37a2omtFiEJC+J6tXXg1g+y82XNJ3hv4Gevi+ObA9i0cECMZIWwcm6cvQELGKYNtykH +t/xcL1+QQXHMPnuRucPgIp3QPaYawWBD8WHUS68kjnG9du01YCV36IlxH3GM//NOtdt K413G6k5DrTX107DoOx0yQvI408KGtvDWtjGdsYKylSdkO7MOwIoPqdM1GcxOoO8x5Zd HNOA== X-Gm-Message-State: APjAAAXhyEpPhbkm6caMDkgdKNxazToXohn9OfoIbk/Rex24Y3XmMlUH oGuo2xmZsQwTEHBpxbmOM+dMgcnDF3aBOYlmanlYeQ== X-Google-Smtp-Source: APXvYqz95u8SOpZ8CKpbA/DJiP9eST+uXrcgaIItAAur7JD+mN8MzKVC12sI0+N58LUhcO4C5kYwuTsqYm/TbJd/HRQ= X-Received: by 2002:ab0:6387:: with SMTP id y7mr6108565uao.110.1571419131321; Fri, 18 Oct 2019 10:18:51 -0700 (PDT) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20191018161033.261971-19-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Fri, 18 Oct 2019 10:18:40 -0700 Message-ID: Subject: Re: [PATCH 18/18] arm64: implement Shadow Call Stack To: Jann Horn Cc: Will Deacon , Catalin Marinas , Steven Rostedt , Ard Biesheuvel , Dave Martin , Kees Cook , Laura Abbott , Mark Rutland , Nick Desaulniers , clang-built-linux , Kernel Hardening , linux-arm-kernel , kernel list 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, Oct 18, 2019 at 10:13 AM Jann Horn wrote: > These things should probably be __always_inline or something like > that? If the compiler decides not to inline them (e.g. when called > from scs_thread_switch()), stuff will blow up, right? Correct. I'll change these to __always_inline in v2. I think there might be other places in the kernel where not inlining a static inline function would break things, but there's no need to add more. > This is different from the intended protection level according to > , which > talks about "a runtime that avoids exposing the address of the shadow > call stack to attackers that can read arbitrary memory". Of course, > that's extremely hard to implement in the context of the kernel, where > you can see all the memory management data structures and all physical > memory. Yes, the security guarantees in the kernel are different as hiding shadow stack pointers is more challenging. > You might want to write something in the cover letter about what the > benefits of this mechanism compared to STACKPROTECTOR are in the > context of the kernel, including a specific description of which types > of attacker capabilities this is supposed to defend against. Sure, I'll add something about that in v2. Thanks. 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 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 CBF4ACA9EA9 for ; Fri, 18 Oct 2019 17:19:06 +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 9CEFE21897 for ; Fri, 18 Oct 2019 17:19:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eU2kOQzl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="vsQmN/Ap" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9CEFE21897 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=AZCTwV5VOwaPUk96pJ8P6tra2k4JXQXr1hqR7y3yJLs=; b=eU2kOQzlEkTJus FbqzTgxV6kg/YbWXj9YMAOU6tsZYwXYhr+a2xiy2iNBbStBg4zGoB9O9A4wkoZUPHbGMkz2KDDatB CL8hikGa1FdJtMC+LAxvd73ZvC80aNtgyMqmwliaZ1b6sj0WPBQUsA2JirCVy12V6TM54zZ7dp7fK MqAA2D6ZBvpe7WhPidO5FxSxaSkJI0nbERiyWFEbwpeuGrCey0z80/OvlcvrMU/mYu59ZOhyqXKkU xchwhLpLjNCZA2LHO/sXKsOVDMsl94EaDIQAlHD6ICbN9KsDGHjA5jl27LWlw5M8iUd6Qlu7xPhG5 Vj8Gb3ITOdEF+PxaNUDA==; 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 1iLVty-0007ea-O9; Fri, 18 Oct 2019 17:18:58 +0000 Received: from mail-ua1-x941.google.com ([2607:f8b0:4864:20::941]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iLVtt-0007ZL-Bc for linux-arm-kernel@lists.infradead.org; Fri, 18 Oct 2019 17:18:55 +0000 Received: by mail-ua1-x941.google.com with SMTP id n2so1934551ual.11 for ; Fri, 18 Oct 2019 10:18:52 -0700 (PDT) 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=0HIzf5D0wGbvpmxHvIyOvn+49UWE2lHPyTZCg3y02sw=; b=vsQmN/ApjkODa5g1BT612x/4GGL20gZVZE8EGaFhwsXbdCcFD/fycGlyho4gxOJTFH UNt9ub/I4P/h809X5D4yAx7rCwQfs1BEVFWXiVYtxsoUMxjlzIEJPcfVyB8tF344B2aC FjFd1SH8THaH/Pw81yxXP9FQn01T7I+/YsrNyL9mssL2T1CuwuFiQluKl0/fFUrg4HLq GlWt1dVIFhyf7eCqu7QIp5RVLWS2ZUOsoD7wzE3W1jtwUAY4NHDTbaS0+XPgu0S1K6/l VhJ5hk4oAgFzg9fAGqgifT4d4FsvndIJvJc42Q3EHtKExcLFN4z8Qliw6bt6wkdvd8lR FnJw== 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=0HIzf5D0wGbvpmxHvIyOvn+49UWE2lHPyTZCg3y02sw=; b=AkUxdJ/Af8GWsE8eYwbfNDxabm3fDqtCuT5jnyX7YJgTMjZObu7bOvsGb1EcrdIMyt tlWkInAKC8tIWy+1tWEZSB/dsHaD83O1XB3/RnBrYDnZ4ElUKjxNMjCXkmoLoLl/74eu fchb2AmI/aGyoQaMB6BHqnRb5BDRcXMYaTWBp0YMaGil/3QahvaBfIhUdetILAnAdheZ Sz3ERKmKtHJ7DsjeZRpO4UIHxfn/JrWI4yh7yIIMQmbUfYW7HuGz8gP6nl8sqeqoPmwN Nq1YYhK/z8okO1SV4UeF4IsBjXiBmXVeH4NhqsnYWFTmTb1rZ4XMMjFs47Vk093BDSmK wwwQ== X-Gm-Message-State: APjAAAUeyRUVcKz8qZXuF/vBzn+EbEQVcwL2yxaw+HEQ+OR08mSmk6JJ jd//ZPIqUWXWc64a7BXBzEQOFe28alIun08ualA9tA== X-Google-Smtp-Source: APXvYqz95u8SOpZ8CKpbA/DJiP9eST+uXrcgaIItAAur7JD+mN8MzKVC12sI0+N58LUhcO4C5kYwuTsqYm/TbJd/HRQ= X-Received: by 2002:ab0:6387:: with SMTP id y7mr6108565uao.110.1571419131321; Fri, 18 Oct 2019 10:18:51 -0700 (PDT) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20191018161033.261971-19-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Fri, 18 Oct 2019 10:18:40 -0700 Message-ID: Subject: Re: [PATCH 18/18] arm64: implement Shadow Call Stack To: Jann Horn X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191018_101853_443107_F42AAA4A X-CRM114-Status: GOOD ( 12.81 ) 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 , Catalin Marinas , Kernel Hardening , Nick Desaulniers , kernel list , Steven Rostedt , clang-built-linux , 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, Oct 18, 2019 at 10:13 AM Jann Horn wrote: > These things should probably be __always_inline or something like > that? If the compiler decides not to inline them (e.g. when called > from scs_thread_switch()), stuff will blow up, right? Correct. I'll change these to __always_inline in v2. I think there might be other places in the kernel where not inlining a static inline function would break things, but there's no need to add more. > This is different from the intended protection level according to > , which > talks about "a runtime that avoids exposing the address of the shadow > call stack to attackers that can read arbitrary memory". Of course, > that's extremely hard to implement in the context of the kernel, where > you can see all the memory management data structures and all physical > memory. Yes, the security guarantees in the kernel are different as hiding shadow stack pointers is more challenging. > You might want to write something in the cover letter about what the > benefits of this mechanism compared to STACKPROTECTOR are in the > context of the kernel, including a specific description of which types > of attacker capabilities this is supposed to defend against. Sure, I'll add something about that in v2. Thanks. 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 5403DCA9EA9 for ; Fri, 18 Oct 2019 17:55:12 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id A04F121835 for ; Fri, 18 Oct 2019 17:55:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vsQmN/Ap" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A04F121835 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-17053-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 13753 invoked by uid 550); 18 Oct 2019 17:54:41 -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 26540 invoked from network); 18 Oct 2019 17:19:03 -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=0HIzf5D0wGbvpmxHvIyOvn+49UWE2lHPyTZCg3y02sw=; b=vsQmN/ApjkODa5g1BT612x/4GGL20gZVZE8EGaFhwsXbdCcFD/fycGlyho4gxOJTFH UNt9ub/I4P/h809X5D4yAx7rCwQfs1BEVFWXiVYtxsoUMxjlzIEJPcfVyB8tF344B2aC FjFd1SH8THaH/Pw81yxXP9FQn01T7I+/YsrNyL9mssL2T1CuwuFiQluKl0/fFUrg4HLq GlWt1dVIFhyf7eCqu7QIp5RVLWS2ZUOsoD7wzE3W1jtwUAY4NHDTbaS0+XPgu0S1K6/l VhJ5hk4oAgFzg9fAGqgifT4d4FsvndIJvJc42Q3EHtKExcLFN4z8Qliw6bt6wkdvd8lR FnJw== 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=0HIzf5D0wGbvpmxHvIyOvn+49UWE2lHPyTZCg3y02sw=; b=ZNKranOj1EHzul61xMHbomJ6+ZtPZVZEWzs971jMNZLGX4wBJZclEP9FoBRGqsFNwj T0wHt95xiq7Z16Qwl8rAhfArMAl1MHhVD+9aTmObiB+Qol6jnk5u2myXQHI4eh3gVXoO hfvnARsTskZYF5SgGGDUc0DyXFTJFG3Rqe3SJ1VQXBwYmjayEw+jb12TAEzqWk5pCmJR Ped3IT0g15SXoN8PwcrmMMuctOzKOJ2hTXGMq5mUktgzNsp1iyypKWs0ZIAOyOZ2on3n e5uHi8xn3oHEM3YFAXRVxGDGlDRukJ2qRBSy2BxgnveZGT+qGhh7l6w9PWsMl4HgKwPo Getg== X-Gm-Message-State: APjAAAV7nq0/yH67ZbeqBAsnAkvBnzH9u2xOefy/mAMzVA6DncM39lo2 8vnVcu50F4Be0Vd5pih8yKCxaZ2ZhoVS+xVGpfPFYw== X-Google-Smtp-Source: APXvYqz95u8SOpZ8CKpbA/DJiP9eST+uXrcgaIItAAur7JD+mN8MzKVC12sI0+N58LUhcO4C5kYwuTsqYm/TbJd/HRQ= X-Received: by 2002:ab0:6387:: with SMTP id y7mr6108565uao.110.1571419131321; Fri, 18 Oct 2019 10:18:51 -0700 (PDT) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20191018161033.261971-19-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Fri, 18 Oct 2019 10:18:40 -0700 Message-ID: Subject: Re: [PATCH 18/18] arm64: implement Shadow Call Stack To: Jann Horn Cc: Will Deacon , Catalin Marinas , Steven Rostedt , Ard Biesheuvel , Dave Martin , Kees Cook , Laura Abbott , Mark Rutland , Nick Desaulniers , clang-built-linux , Kernel Hardening , linux-arm-kernel , kernel list Content-Type: text/plain; charset="UTF-8" On Fri, Oct 18, 2019 at 10:13 AM Jann Horn wrote: > These things should probably be __always_inline or something like > that? If the compiler decides not to inline them (e.g. when called > from scs_thread_switch()), stuff will blow up, right? Correct. I'll change these to __always_inline in v2. I think there might be other places in the kernel where not inlining a static inline function would break things, but there's no need to add more. > This is different from the intended protection level according to > , which > talks about "a runtime that avoids exposing the address of the shadow > call stack to attackers that can read arbitrary memory". Of course, > that's extremely hard to implement in the context of the kernel, where > you can see all the memory management data structures and all physical > memory. Yes, the security guarantees in the kernel are different as hiding shadow stack pointers is more challenging. > You might want to write something in the cover letter about what the > benefits of this mechanism compared to STACKPROTECTOR are in the > context of the kernel, including a specific description of which types > of attacker capabilities this is supposed to defend against. Sure, I'll add something about that in v2. Thanks. Sami