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: <a3965437-bd7d-41cc-abb6-0311e5d933bf@app.fastmail.com>
Date: Tue, 18 Jun 2024 08:46:18 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kees Cook" <kees@...nel.org>
Cc: "Mark Rutland" <mark.rutland@....com>,
 "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:31, Kees Cook 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:
>
> 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

Thanks for the summary. 

Right now of course we need to fix the bug from 9c573cd31343
("randomize_kstack: Improve entropy diffusion") that has led to
using full 10 bits after diffusion but put fewer bits in than
possible on some architectures. Unless you want to revert that
patch, we should ensure that any truncation is only done in
KSTACK_OFFSET_MAX() rather than passed into
choose_random_kstack_offset().

     Arnd