linux-hardening - Re: [PATCH] remove AND operation in choose_random_kstack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZnF0qY-WoAGVuXXh@J2N7QTR9R3>
Date: Tue, 18 Jun 2024 12:51:05 +0100
From: Mark Rutland <mark.rutland@....com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Kees Cook <kees@...nel.org>, Yuntao Liu <liuyuntao12@...wei.com>,
	x86@...nel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
	linux-hardening@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Heiko Carstens <hca@...ux.ibm.com>,
	gor@...ux.ibm.com, Alexander Gordeev <agordeev@...ux.ibm.com>,
	Christian Borntraeger <borntraeger@...ux.ibm.com>,
	Sven Schnelle <svens@...ux.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Gustavo A. R. Silva" <gustavoars@...nel.org>,
	Leonardo Bras <leobras@...hat.com>, Mark Brown <broonie@...nel.org>,
	imbrenda@...ux.ibm.com, pawan.kumar.gupta@...ux.intel.com
Subject: Re: [PATCH] remove AND operation in choose_random_kstack_offset()

On Tue, Jun 18, 2024 at 01:14:58PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 18, 2024, at 12:45, Mark Rutland wrote:
> > 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:
> 
> > 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".
> 
> Absolutely agreed, and the commit message should also clarify that
> the increase has already happened as an unintended side-effect
> of commit 9c573cd31343 ("randomize_kstack: Improve entropy
> diffusion").

FWIW, I think that alone is a reasonable justification.

> > * The comments in architecture code referring to the masking get
> >   removed/updated along with the masking.
> 
> Right.
> 
> FWIW, I also wouldn't mind to having a compile-time option
> that configures the number of random bits on the stack offset,
> but my preference here is to have a reasonable default and
> not need a config option.

I agree; I think we should avoid a config option unless we actually see
a need for it in testing.

Mark.