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 Archived-At: List-Archive: 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