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 F234FCA9EA0 for ; Fri, 18 Oct 2019 17:13:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C26BC21835 for ; Fri, 18 Oct 2019 17:13:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="b3XVK3oU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2505385AbfJRRNU (ORCPT ); Fri, 18 Oct 2019 13:13:20 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:40935 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388893AbfJRRNU (ORCPT ); Fri, 18 Oct 2019 13:13:20 -0400 Received: by mail-ot1-f66.google.com with SMTP id y39so5575664ota.7 for ; Fri, 18 Oct 2019 10:13:19 -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=hDou5Z7AnxlXNsw3EcpY942CX+9awGJrPWvG/Uzq/u0=; b=b3XVK3oUecv8zhJLi8wBDU7dsrLDXf1OhUshJUWrVsOCyqSXhdbO23VgWxMa1R1urV O3E1ni9xUlU5exVU2VN35NKkne1rfv/1j3PKa/bWhKm2DIro7eXxLtItOmaC3XOEVOA9 ZLv/TVDdBvoFM3TfTMn3ONMlD7GUkxnZaMFWTTyGh44WPUx0cpIo6kEG+IVNJg1lrwBL WL9jGxsuEWtxSL3cJ9QRV9f3OdnQ5+aRdNlpTr9CoWQjI8f2G640+Y7wNI2i7oNG2Rsy O6DYbrPat+1p7BnU+R03ZNEIzhlMSWVKzCr2Ut84sHvq/7dPn/M9sIfCLCn29vsJ4VLN Awew== 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=hDou5Z7AnxlXNsw3EcpY942CX+9awGJrPWvG/Uzq/u0=; b=FXSVrD6iSI8sEmBOC72WuTUnO7Bp1205DA+Ug4yz071EFQHUuwPG6IeCuUYwMijK+q w3iuGN+kHcBZtgLG6QIW82w78s7ORdDv0x/owDvp3flhuCJY192zIV5Aw5iAAUN3Xrvu t3U7RhYua1g+Z0K2Vjv+tzE6ZTctq3uZV6pdvNb6eetMCvPoRB4Qb7sFAs8OIrInm2OM 4OUeXm94C+V2/Ip5X2GR1+HQUhthXkcbb6mqfUpizd2Z1jL1pnhTo2QQO9yJOO7oLaJl MEjBQIAvRYTOHHWRCFaB+VGDSC5NYtcTibNzhAUeyQbZlS/tP8/9KVa9We04vSpXVpnX v9hQ== X-Gm-Message-State: APjAAAWDgkOstf6/FVR7vzfA5SZ7xfgO+7ZujCZfNBPILEktE2+JjDvc sbA4O1y5qHlH3sT4Ba2mMN/rGOieyHQIbrFh7BEaPg== X-Google-Smtp-Source: APXvYqzk63aLcaDtSLDQmaTKnKA/9Iqjg+1oUYrcegXtjis3ArS3MzocA0YvPnHL7bljLig2r8OQsin0dsxx/YoQ1HQ= X-Received: by 2002:a05:6830:10cc:: with SMTP id z12mr8713226oto.110.1571418798907; Fri, 18 Oct 2019 10:13:18 -0700 (PDT) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20191018161033.261971-19-samitolvanen@google.com> In-Reply-To: <20191018161033.261971-19-samitolvanen@google.com> From: Jann Horn Date: Fri, 18 Oct 2019 19:12:52 +0200 Message-ID: Subject: Re: [PATCH 18/18] arm64: implement Shadow Call Stack To: Sami Tolvanen 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@lists.infradead.org, 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 6:16 PM Sami Tolvanen wrote: > This change implements shadow stack switching, initial SCS set-up, > and interrupt shadow stacks for arm64. [...] > +static inline void scs_save(struct task_struct *tsk) > +{ > + void *s; > + > + asm volatile("mov %0, x18" : "=r" (s)); > + task_set_scs(tsk, s); > +} > + > +static inline void scs_load(struct task_struct *tsk) > +{ > + asm volatile("mov x18, %0" : : "r" (task_scs(tsk))); > + task_set_scs(tsk, NULL); > +} 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? > +static inline void scs_thread_switch(struct task_struct *prev, > + struct task_struct *next) > +{ > + scs_save(prev); > + scs_load(next); > + > + if (unlikely(scs_corrupted(prev))) > + panic("corrupted shadow stack detected inside scheduler\n"); > +} [...] > +#ifdef CONFIG_SHADOW_CALL_STACK > +DECLARE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr); > +#endif If an attacker has a leak of some random function pointer to find the ASLR base address, they'll know where irq_shadow_call_stack_ptr is. With an arbitrary read (to read irq_shadow_call_stack_ptr[sched_getcpu()]) followed by an arbitrary write, they'd be able to overwrite the shadow stack. Or with just an arbitrary write without a read, they could change irq_shadow_call_stack_ptr[sched_getcpu()] to point elsewhere. 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. 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. 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 110A3CA9EA0 for ; Fri, 18 Oct 2019 17:13:31 +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 D0FF521925 for ; Fri, 18 Oct 2019 17:13:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="c+dzIwok"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="b3XVK3oU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0FF521925 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=GarPHwggSeYkyA1JOtQxeKZV4Bf4ydgbyYF5C3gvh7w=; b=c+dzIwokLOOGer KKIzeXcBL49KwqJ9xRp9yeJChJDrxj3Nd2XDX7nGjxO/5Uftpmx0RwLMo+f8CBfs94kDiCPYj0yri YVPrlDjZPHSan7W5r1kFCKG7qqF+Ru6uCkVOGzIm9AdtqMbo44uZlF+HncGxcjeFHerMLU6i+mOj6 qN9Y4uW5XJHproKWJvtbHCB5Q1hlGn32kySEmbkdqhunslL984gxftQc+1QozinAQD88k81JDuZoL Tf5puwyxaNdvokK/U36vkJWoptcgOhYpPUi1UWrq4Nz6uBwynmbWFHN89uQ4VhuT3DV92320GEJ4/ luJlc9YzrIXUZ7uKdmDQ==; 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 1iLVog-0005L4-5L; Fri, 18 Oct 2019 17:13:30 +0000 Received: from mail-ot1-x341.google.com ([2607:f8b0:4864:20::341]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iLVoa-0005JL-1I for linux-arm-kernel@lists.infradead.org; Fri, 18 Oct 2019 17:13:28 +0000 Received: by mail-ot1-x341.google.com with SMTP id s22so5578335otr.6 for ; Fri, 18 Oct 2019 10:13:19 -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=hDou5Z7AnxlXNsw3EcpY942CX+9awGJrPWvG/Uzq/u0=; b=b3XVK3oUecv8zhJLi8wBDU7dsrLDXf1OhUshJUWrVsOCyqSXhdbO23VgWxMa1R1urV O3E1ni9xUlU5exVU2VN35NKkne1rfv/1j3PKa/bWhKm2DIro7eXxLtItOmaC3XOEVOA9 ZLv/TVDdBvoFM3TfTMn3ONMlD7GUkxnZaMFWTTyGh44WPUx0cpIo6kEG+IVNJg1lrwBL WL9jGxsuEWtxSL3cJ9QRV9f3OdnQ5+aRdNlpTr9CoWQjI8f2G640+Y7wNI2i7oNG2Rsy O6DYbrPat+1p7BnU+R03ZNEIzhlMSWVKzCr2Ut84sHvq/7dPn/M9sIfCLCn29vsJ4VLN Awew== 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=hDou5Z7AnxlXNsw3EcpY942CX+9awGJrPWvG/Uzq/u0=; b=XqtKoCnMRr8kB/bfGwGO5TBlTEIA+zJmCwDob9f+wxcsrr5/mmnoSAbzlPWB79pm27 evQ5X2s8h/y63tgNFjjiTU5WSilMUq2xN2WW4wP3UZO4EU9tIXzFpqgEaS/WUDvbV4kX g83abgXzaGWtTc6CXvNXhFtR1b6dyQuW5M4phxt9PGPkLIL0EpWm+JUxLmDZBATr6G08 Dt8zPxfV3EgiQtsoeJDmtvXaDJts0GNesnbrXb3V9Whtcn/YxWkxfumLvX4sWw16fbiX LzRgdEbe4ibQz+Hgd4gZ5vXmmQlMn4AZ6NsMz6wutyN5qhtif64tHPjtfCzuIjRrTAbv rQvg== X-Gm-Message-State: APjAAAUMBHSFXamnLuKogW8asqE4ziteSPbJWa4NO+dfLPFOPeur0Zj0 hrn1E+cEDDy8oPBYDzNv7Kw3/EZWe7EZ5V9wt2tw2Q== X-Google-Smtp-Source: APXvYqzk63aLcaDtSLDQmaTKnKA/9Iqjg+1oUYrcegXtjis3ArS3MzocA0YvPnHL7bljLig2r8OQsin0dsxx/YoQ1HQ= X-Received: by 2002:a05:6830:10cc:: with SMTP id z12mr8713226oto.110.1571418798907; Fri, 18 Oct 2019 10:13:18 -0700 (PDT) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20191018161033.261971-19-samitolvanen@google.com> In-Reply-To: <20191018161033.261971-19-samitolvanen@google.com> From: Jann Horn Date: Fri, 18 Oct 2019 19:12:52 +0200 Message-ID: Subject: Re: [PATCH 18/18] arm64: implement Shadow Call Stack To: Sami Tolvanen X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191018_101324_077818_16A2007D X-CRM114-Status: GOOD ( 12.12 ) 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@lists.infradead.org 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 6:16 PM Sami Tolvanen wrote: > This change implements shadow stack switching, initial SCS set-up, > and interrupt shadow stacks for arm64. [...] > +static inline void scs_save(struct task_struct *tsk) > +{ > + void *s; > + > + asm volatile("mov %0, x18" : "=r" (s)); > + task_set_scs(tsk, s); > +} > + > +static inline void scs_load(struct task_struct *tsk) > +{ > + asm volatile("mov x18, %0" : : "r" (task_scs(tsk))); > + task_set_scs(tsk, NULL); > +} 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? > +static inline void scs_thread_switch(struct task_struct *prev, > + struct task_struct *next) > +{ > + scs_save(prev); > + scs_load(next); > + > + if (unlikely(scs_corrupted(prev))) > + panic("corrupted shadow stack detected inside scheduler\n"); > +} [...] > +#ifdef CONFIG_SHADOW_CALL_STACK > +DECLARE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr); > +#endif If an attacker has a leak of some random function pointer to find the ASLR base address, they'll know where irq_shadow_call_stack_ptr is. With an arbitrary read (to read irq_shadow_call_stack_ptr[sched_getcpu()]) followed by an arbitrary write, they'd be able to overwrite the shadow stack. Or with just an arbitrary write without a read, they could change irq_shadow_call_stack_ptr[sched_getcpu()] to point elsewhere. 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. 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. _______________________________________________ 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 D8423CA9EA9 for ; Fri, 18 Oct 2019 17:13:38 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 2BDE721925 for ; Fri, 18 Oct 2019 17:13:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="b3XVK3oU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BDE721925 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-17043-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 24247 invoked by uid 550); 18 Oct 2019 17:13:31 -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 24229 invoked from network); 18 Oct 2019 17:13:31 -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=hDou5Z7AnxlXNsw3EcpY942CX+9awGJrPWvG/Uzq/u0=; b=b3XVK3oUecv8zhJLi8wBDU7dsrLDXf1OhUshJUWrVsOCyqSXhdbO23VgWxMa1R1urV O3E1ni9xUlU5exVU2VN35NKkne1rfv/1j3PKa/bWhKm2DIro7eXxLtItOmaC3XOEVOA9 ZLv/TVDdBvoFM3TfTMn3ONMlD7GUkxnZaMFWTTyGh44WPUx0cpIo6kEG+IVNJg1lrwBL WL9jGxsuEWtxSL3cJ9QRV9f3OdnQ5+aRdNlpTr9CoWQjI8f2G640+Y7wNI2i7oNG2Rsy O6DYbrPat+1p7BnU+R03ZNEIzhlMSWVKzCr2Ut84sHvq/7dPn/M9sIfCLCn29vsJ4VLN Awew== 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=hDou5Z7AnxlXNsw3EcpY942CX+9awGJrPWvG/Uzq/u0=; b=SL5j5OQVpUcF5AaJgc/VMNt91X+KYo8K2Il9PIcBHrHkiYdjEn8G0vApuGr8SapZa2 GPXWMWEZK4ANRc5VW3G+PTTwaJ5j7iaTjrynNokMaNzLf/KJwG48hUMEf4T4NGFK1keZ hNzrqzyKJDTPT+RuBLYtzd+eiaoPu6xNz1WjLiaUDGWyyGw0TdLX1jRKKP9lI7d+kOPk HgvRUT/NlCDic6txbDWEEajK0uvbdxhZIaH7kWahQMfpxhb4bw8Yqelm8xiPi1ZspmqP qybE8lhbPzSs1VC8GneJFP1Ph6vNLu/oQNcmTT2zuvRXdKCj25EObi0GRWeioLh1ThR5 +YCQ== X-Gm-Message-State: APjAAAXJ8bELh3+ZwUFJ0DvAb+0GP+JwTdgjzjj7y4qGN+Rf/vf15yUw AGQaYfdnGKLcEoikuFLYHxWTl0Eq0YJhZnSdarfkpw== X-Google-Smtp-Source: APXvYqzk63aLcaDtSLDQmaTKnKA/9Iqjg+1oUYrcegXtjis3ArS3MzocA0YvPnHL7bljLig2r8OQsin0dsxx/YoQ1HQ= X-Received: by 2002:a05:6830:10cc:: with SMTP id z12mr8713226oto.110.1571418798907; Fri, 18 Oct 2019 10:13:18 -0700 (PDT) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20191018161033.261971-19-samitolvanen@google.com> In-Reply-To: <20191018161033.261971-19-samitolvanen@google.com> From: Jann Horn Date: Fri, 18 Oct 2019 19:12:52 +0200 Message-ID: Subject: Re: [PATCH 18/18] arm64: implement Shadow Call Stack To: Sami Tolvanen 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@lists.infradead.org, kernel list Content-Type: text/plain; charset="UTF-8" On Fri, Oct 18, 2019 at 6:16 PM Sami Tolvanen wrote: > This change implements shadow stack switching, initial SCS set-up, > and interrupt shadow stacks for arm64. [...] > +static inline void scs_save(struct task_struct *tsk) > +{ > + void *s; > + > + asm volatile("mov %0, x18" : "=r" (s)); > + task_set_scs(tsk, s); > +} > + > +static inline void scs_load(struct task_struct *tsk) > +{ > + asm volatile("mov x18, %0" : : "r" (task_scs(tsk))); > + task_set_scs(tsk, NULL); > +} 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? > +static inline void scs_thread_switch(struct task_struct *prev, > + struct task_struct *next) > +{ > + scs_save(prev); > + scs_load(next); > + > + if (unlikely(scs_corrupted(prev))) > + panic("corrupted shadow stack detected inside scheduler\n"); > +} [...] > +#ifdef CONFIG_SHADOW_CALL_STACK > +DECLARE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr); > +#endif If an attacker has a leak of some random function pointer to find the ASLR base address, they'll know where irq_shadow_call_stack_ptr is. With an arbitrary read (to read irq_shadow_call_stack_ptr[sched_getcpu()]) followed by an arbitrary write, they'd be able to overwrite the shadow stack. Or with just an arbitrary write without a read, they could change irq_shadow_call_stack_ptr[sched_getcpu()] to point elsewhere. 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. 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.