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 E4D89C27C79 for ; Mon, 17 Jun 2024 23:32:03 +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=+LPMMVZEA4PtVkUZHpv2QVxSPt4b6YYWBEZ7Xa3Avsc=; b=bpGQ6Z9LmoPzlgXozFbiAPHF/a aZxTpPPeB8WpaSuaJLYeFStG/N7fM6rXHaQ+8TmxTZo3k3BsPEpj86+C4hcMMwRRzueHpfOr3YFty qKtjItN7mJz+Kw7dR3l17VW3v8YO021tboD6IxdxKdW89NJsz+v5zjiw1p6LvNg3C45TIB+bJtpd9 OYM1U6gAz7NhD+iscNRsOWaDZweCl846dQNyGMBB7NBIYKOjgli9D82/z/vMG9kxF+NFZL9uJsKr7 ZPwocWAY2IevC+FkUDW30sgNC2wvRDydBAHU/NV6vpO+PEPTmvNBLQoyw408nBIMAC+kAOHyAxtVp kmai3IWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJLpH-0000000Cvv0-26xY; Mon, 17 Jun 2024 23:31:51 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJLpE-0000000Cvtz-3jxo for linux-arm-kernel@lists.infradead.org; Mon, 17 Jun 2024 23:31:50 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 57D80614BE; Mon, 17 Jun 2024 23:31:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2906C2BD10; Mon, 17 Jun 2024 23:31:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718667108; bh=4KZkD3adnWFBE0CL7l4ZcutJUzuc0oVMJV2Ijc+6+ts=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=g51AgzHVXFVuX6oGkjN69HCIu9soTKyZLJzm4ofCyzigdOGRQanOnL35s24Aol1FH zpXTOqnhgt4mFbc/KwrPpE+mGpwzhyHw1gfihkTb9T/Cbs1ZcMjMtuZdeLeOVGUuf8 hdNaotoUTLyCsSDOOBRAdewJvF2/lMiZreACRkKtZIUm8wZsXqNV7oregbbc2ZmEtZ +mpfb3S2Xrny33zu+Cq4Fq+QrYuNtGhrBvgkYu2D+OPJa2kVNYFlhdJVCtJ4m+Fza9 vu3/y88gXe3zIfSQACIyaGkvQTm3p3CpKSR8tOFbXiMtuOxApbr4s2SBry50aiHwFi NBWsWZdhpJc4Q== Date: Mon, 17 Jun 2024 16:31:47 -0700 From: Kees Cook To: Arnd Bergmann Cc: Mark Rutland , 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: <202406171618.A92D064@keescook> 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-20240617_163149_036773_F59BE86C X-CRM114-Status: GOOD ( 30.29 ) 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 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. I'm all for more entropy, but arch maintainers had wanted specific control over this value, and given the years of bikeshedding over the feature, I'm not inclined dive back into that debate, but okay. FWIW, the here's the actual entropy (due to stack alignment enforced by the compiler for the given arch ABI). standard cap is 0x3FF (10 bits). arm64: capped at 0x1FF (9 bits), 5 bits effective powerpc: uncapped (10 bits), 6 or 7 bits effective riscv: uncapped (10 bits), 6 bits effective x86: capped at 0xFF (8 bits), 5 (x86_64) or 6 (ia32) bits effective s390: capped at 0xFF (8 bits), undocumented effective entropy So if x86, arm64, and s390 maintainers are okay with it, we can try dropping the masks on those architectures. They would gain 2, 1, and 2 bits respectively. -Kees -- Kees Cook