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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4EEA6C27C4F for ; Tue, 18 Jun 2024 10:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NGN+CZ/zZKVGztYqpDeH5LL7kfEctIHp2sEN5eTh7aE=; b=SN0eFTSJqldQ1BNzq3IEtrzjYJ E7Jaz/3TqSm+6sKds+5Fg2l8LZptY/rEYU5Bc4aI39ryEOo/NP+ypt1+65LtdrycbsDVjL/d9mdZM 1O4w5GLFOivapDi4iHzqt9fKFtOevrswAVltKxypNHfa8UKEH4tZZHoxedqajwLfB51fJJdkeH8TA GfC+5KtHXgo+GAkHHVrdJ4eApIhGmxVbMxryPUeIBPjm/wiURxvKpmGM4+5QEcSdAFoPZI9Vv/3nv mEOsbs9ASPlFHOXEZeXAQIXS5hByzVh8g6XvTkh5atmuJmLaCZoKYk0rbxAP+N1DxVXiVy1HgdUer NDGUkJDw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJWLM-0000000EQso-26sS; Tue, 18 Jun 2024 10:45:40 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJWLJ-0000000EQrI-3lVv for linux-arm-kernel@lists.infradead.org; Tue, 18 Jun 2024 10:45:39 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C6EF0DA7; Tue, 18 Jun 2024 03:45:55 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B48F53F6A8; Tue, 18 Jun 2024 03:45:27 -0700 (PDT) Date: Tue, 18 Jun 2024 11:45:22 +0100 From: Mark Rutland To: Arnd Bergmann Cc: Kees Cook , Yuntao Liu , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-hardening@vger.kernel.org, Catalin Marinas , Will Deacon , Heiko Carstens , gor@linux.ibm.com, Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , "Gustavo A. R. Silva" , Leonardo Bras , Mark Brown , imbrenda@linux.ibm.com, pawan.kumar.gupta@linux.intel.com Subject: Re: [PATCH] remove AND operation in choose_random_kstack_offset() Message-ID: References: <20240617133721.377540-1-liuyuntao12@huawei.com> <202406171122.B5FDA6A@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240618_034538_047131_5B04C6D9 X-CRM114-Status: GOOD ( 30.42 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Arnd, On Mon, Jun 17, 2024 at 10:33:08PM +0200, Arnd Bergmann wrote: > On Mon, Jun 17, 2024, at 20:22, Kees Cook wrote: > > On Mon, Jun 17, 2024 at 04:52:15PM +0100, Mark Rutland wrote: > >> On Mon, Jun 17, 2024 at 01:37:21PM +0000, Yuntao Liu wrote: > >> > Since the offset would be bitwise ANDed with 0x3FF in > >> > add_random_kstack_offset(), so just remove AND operation here. > >> > > >> > Signed-off-by: Yuntao Liu > >> > >> The comments in arm64 and x86 say that they're deliberately capping the > >> offset at fewer bits than the result of KSTACK_OFFSET_MAX() masking the > >> value with 0x3FF. > >> > >> Maybe it's ok to expand that, but if that's the case the commit message > >> needs to explain why it's safe add extra bits (2 on arm64, 3 on s39 and > >> x86), and those comments need to be updated accordingly. > >> > >> As-is, I do not think this patch is ok. > > > > Yeah, I agree: the truncation is intentional and tuned to the > > architecture. > > It may be intentional, but it's clearly nonsense: there is nothing > inherent to the architecture that means we have can go only 256 > bytes instead of 512 bytes into the 16KB available stack space. > > As far as I can tell, any code just gets bloated to the point > where it fills up the available memory, regardless of how > much you give it. I'm sure one can find code paths today that > exceed the 16KB, so there is no point pretending that 15.75KB > is somehow safe to use while 15.00KB is not. > > I'm definitely in favor of making this less architecture > specific, we just need to pick a good value, and we may well > end up deciding to use less than the default 1KB. We can also > go the opposite way and make the limit 4KB but then increase > the default stack size to 20KB for kernels that enable > randomization. Sorry, to be clear, I'm happy for this to change, so long as: * The commit message explains why that's safe. IIUC this goes from 511 to 1023 bytes on arm64, which is ~3% of the stack, so maybe that is ok. It'd be nice to see any rationale/analysis beyond "the offset would be bitwise ANDed with 0x3FF". * The comments in architecture code referring to the masking get removed/updated along with the masking. My complaint was that the patch didn't do those things. Mark.