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=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 4A29DC43460 for ; Wed, 7 Apr 2021 21:37:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0AFD861279 for ; Wed, 7 Apr 2021 21:37:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233629AbhDGVhU (ORCPT ); Wed, 7 Apr 2021 17:37:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:46074 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232943AbhDGVhT (ORCPT ); Wed, 7 Apr 2021 17:37:19 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C3B6C61205; Wed, 7 Apr 2021 21:37:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617831429; bh=RFTs87mWw0H1NgKsi6VoKVt5brrjF6rBaHU/Q3oJcOY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WJqDViRiIwRnmM3YMFuWCFiMrlE6kkSCoyOgBYkbhZjOWQy+LU7BrpPRbOuAnIFsF 4J/gP9rqJYlB6S+FdzbLcIjo0LcernQ4xfVLqOqv6XGkmkibX8QADKKG3fcooPtKf/ 5R8638Kj2tsbgQh24sFjWw94F41DOwE/FWdgVA/f/ndVKn5v2IJpWT35L9FDhQN1M8 7YU+doIt3z0UPy7LM6kl69Pprv/+2rjJYtlqERzxtnsn4kHhFZFR85DfKdsJCCN2MC yveisBlQZtXyXQVjE49EAxUpf8/ASsb7xDTJT7C5JNvSxDZnwgAs1x90+NU2SUzDxi zRR+acRM2RpKQ== Date: Wed, 7 Apr 2021 22:37:02 +0100 From: Will Deacon To: Kees Cook Cc: Thomas Gleixner , Elena Reshetova , x86@kernel.org, Andy Lutomirski , Peter Zijlstra , Catalin Marinas , Mark Rutland , Alexander Potapenko , Alexander Popov , Ard Biesheuvel , Jann Horn , Vlastimil Babka , David Hildenbrand , Mike Rapoport , Andrew Morton , Jonathan Corbet , Randy Dunlap , kernel-hardening@lists.openwall.com, linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10 3/6] stack: Optionally randomize kernel stack offset each syscall Message-ID: <20210407213702.GB16569@willie-the-truck> References: <20210401232347.2791257-1-keescook@chromium.org> <20210401232347.2791257-4-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210401232347.2791257-4-keescook@chromium.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 01, 2021 at 04:23:44PM -0700, Kees Cook wrote: > This provides the ability for architectures to enable kernel stack base > address offset randomization. This feature is controlled by the boot > param "randomize_kstack_offset=on/off", with its default value set by > CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT. > > This feature is based on the original idea from the last public release > of PaX's RANDKSTACK feature: https://pax.grsecurity.net/docs/randkstack.txt > All the credit for the original idea goes to the PaX team. Note that > the design and implementation of this upstream randomize_kstack_offset > feature differs greatly from the RANDKSTACK feature (see below). [...] > diff --git a/include/linux/randomize_kstack.h b/include/linux/randomize_kstack.h > new file mode 100644 > index 000000000000..fd80fab663a9 > --- /dev/null > +++ b/include/linux/randomize_kstack.h > @@ -0,0 +1,54 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef _LINUX_RANDOMIZE_KSTACK_H > +#define _LINUX_RANDOMIZE_KSTACK_H > + > +#include > +#include > +#include > + > +DECLARE_STATIC_KEY_MAYBE(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, > + randomize_kstack_offset); > +DECLARE_PER_CPU(u32, kstack_offset); > + > +/* > + * Do not use this anywhere else in the kernel. This is used here because > + * it provides an arch-agnostic way to grow the stack with correct > + * alignment. Also, since this use is being explicitly masked to a max of > + * 10 bits, stack-clash style attacks are unlikely. For more details see > + * "VLAs" in Documentation/process/deprecated.rst > + */ > +void *__builtin_alloca(size_t size); > +/* > + * Use, at most, 10 bits of entropy. We explicitly cap this to keep the > + * "VLA" from being unbounded (see above). 10 bits leaves enough room for > + * per-arch offset masks to reduce entropy (by removing higher bits, since > + * high entropy may overly constrain usable stack space), and for > + * compiler/arch-specific stack alignment to remove the lower bits. > + */ > +#define KSTACK_OFFSET_MAX(x) ((x) & 0x3FF) > + > +/* > + * These macros must be used during syscall entry when interrupts and > + * preempt are disabled, and after user registers have been stored to > + * the stack. > + */ This comment is out of date, as this is called from preemptible context on arm64. Does that matter in terms of offset randomness? Will 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=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 EEBD2C433ED for ; Wed, 7 Apr 2021 21:38:41 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 7042C61159 for ; Wed, 7 Apr 2021 21:38:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7042C61159 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+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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=waDB8aVR1AFfg0t0d9RRTx5w5pFCmJHy2Co00WATcy4=; b=HW4c/WPKCeQtWrDFNt5kb70At MnqRupc4vfL/EZUq/NP8kvjciglu90DbS6sIS2RknLrClKQG9rPuW201YZwMzH7OLR6WAd64vgHgs IrobQAoJMulqg/NsU1ZJTnNG6XJ5RMMzh8r5qdIyZUaGKRY/RtWJJCq7iJ20ll8BbBDJQbk0FZ+mj z9oVFTnCB/K5ioSm1psZ7MbA67qSgRo5hyr8szxsdaYUHqg/kgOTKUIdHiEfuQzYqgXQlTRmio8Ns qZOJEgxUERlRfsCgQX9delcQHZiUEBqL2KgliYnuDq6Wa2noJQ2+hNwpR4aMG4smuGG6eNgwbbmbJ NDkD8ihCg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lUFrO-006533-NQ; Wed, 07 Apr 2021 21:37:15 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lUFrL-00652M-2J for linux-arm-kernel@lists.infradead.org; Wed, 07 Apr 2021 21:37:13 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id C3B6C61205; Wed, 7 Apr 2021 21:37:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617831429; bh=RFTs87mWw0H1NgKsi6VoKVt5brrjF6rBaHU/Q3oJcOY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WJqDViRiIwRnmM3YMFuWCFiMrlE6kkSCoyOgBYkbhZjOWQy+LU7BrpPRbOuAnIFsF 4J/gP9rqJYlB6S+FdzbLcIjo0LcernQ4xfVLqOqv6XGkmkibX8QADKKG3fcooPtKf/ 5R8638Kj2tsbgQh24sFjWw94F41DOwE/FWdgVA/f/ndVKn5v2IJpWT35L9FDhQN1M8 7YU+doIt3z0UPy7LM6kl69Pprv/+2rjJYtlqERzxtnsn4kHhFZFR85DfKdsJCCN2MC yveisBlQZtXyXQVjE49EAxUpf8/ASsb7xDTJT7C5JNvSxDZnwgAs1x90+NU2SUzDxi zRR+acRM2RpKQ== Date: Wed, 7 Apr 2021 22:37:02 +0100 From: Will Deacon To: Kees Cook Cc: Thomas Gleixner , Elena Reshetova , x86@kernel.org, Andy Lutomirski , Peter Zijlstra , Catalin Marinas , Mark Rutland , Alexander Potapenko , Alexander Popov , Ard Biesheuvel , Jann Horn , Vlastimil Babka , David Hildenbrand , Mike Rapoport , Andrew Morton , Jonathan Corbet , Randy Dunlap , kernel-hardening@lists.openwall.com, linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10 3/6] stack: Optionally randomize kernel stack offset each syscall Message-ID: <20210407213702.GB16569@willie-the-truck> References: <20210401232347.2791257-1-keescook@chromium.org> <20210401232347.2791257-4-keescook@chromium.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210401232347.2791257-4-keescook@chromium.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210407_223711_508912_32C36474 X-CRM114-Status: GOOD ( 24.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 01, 2021 at 04:23:44PM -0700, Kees Cook wrote: > This provides the ability for architectures to enable kernel stack base > address offset randomization. This feature is controlled by the boot > param "randomize_kstack_offset=on/off", with its default value set by > CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT. > > This feature is based on the original idea from the last public release > of PaX's RANDKSTACK feature: https://pax.grsecurity.net/docs/randkstack.txt > All the credit for the original idea goes to the PaX team. Note that > the design and implementation of this upstream randomize_kstack_offset > feature differs greatly from the RANDKSTACK feature (see below). [...] > diff --git a/include/linux/randomize_kstack.h b/include/linux/randomize_kstack.h > new file mode 100644 > index 000000000000..fd80fab663a9 > --- /dev/null > +++ b/include/linux/randomize_kstack.h > @@ -0,0 +1,54 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef _LINUX_RANDOMIZE_KSTACK_H > +#define _LINUX_RANDOMIZE_KSTACK_H > + > +#include > +#include > +#include > + > +DECLARE_STATIC_KEY_MAYBE(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, > + randomize_kstack_offset); > +DECLARE_PER_CPU(u32, kstack_offset); > + > +/* > + * Do not use this anywhere else in the kernel. This is used here because > + * it provides an arch-agnostic way to grow the stack with correct > + * alignment. Also, since this use is being explicitly masked to a max of > + * 10 bits, stack-clash style attacks are unlikely. For more details see > + * "VLAs" in Documentation/process/deprecated.rst > + */ > +void *__builtin_alloca(size_t size); > +/* > + * Use, at most, 10 bits of entropy. We explicitly cap this to keep the > + * "VLA" from being unbounded (see above). 10 bits leaves enough room for > + * per-arch offset masks to reduce entropy (by removing higher bits, since > + * high entropy may overly constrain usable stack space), and for > + * compiler/arch-specific stack alignment to remove the lower bits. > + */ > +#define KSTACK_OFFSET_MAX(x) ((x) & 0x3FF) > + > +/* > + * These macros must be used during syscall entry when interrupts and > + * preempt are disabled, and after user registers have been stored to > + * the stack. > + */ This comment is out of date, as this is called from preemptible context on arm64. Does that matter in terms of offset randomness? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel