Received-SPF: pass (google.com: domain of linux-kernel+bounces-70123-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sat, 17 Feb 2024 16:25:33 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
To: Kees Cook <keescook@chromium.org>, Jiri Kosina <jikos@kernel.org>
CC: Geert Uytterhoeven <geert@linux-m68k.org>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Qi Zheng <zhengqi.arch@bytedance.com>,
        Alexandre Ghiti <alexghiti@rivosinc.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
        Eric Biederman <ebiederm@xmission.com>,
        Christophe Leroy <christophe.leroy@csgroup.eu>,
        Josh Poimboeuf <jpoimboe@kernel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        Brian Gerst <brgerst@gmail.com>, Bjorn Helgaas <bhelgaas@google.com>,
        Tony Battersby <tonyb@cybernetics.com>, linux-kernel@vger.kernel.org,
        y0un9n132@gmail.com, x86@kernel.org, linux-fsdevel@vger.kernel.org,
        linux-mm@kvack.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH 0/2] Adjust brk randomness
User-Agent: K-9 Mail for Android
In-Reply-To: <20240217062035.work.493-kees@kernel.org>
References: <20240217062035.work.493-kees@kernel.org>
Message-ID: <05E12A71-D8A4-4E6D-9C9D-024251C1BDC7@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On February 16, 2024 10:25:42 PM PST, Kees Cook <keescook@chromium=2Eorg> w=
rote:
>Hi,
>
>It was recently pointed out[1] that x86_64 brk entropy was not great,
>and that on all architectures the brk can (when the random offset is 0)
>be immediately adjacent to =2Ebss, leaving no gap that could stop linear
>overflows from the =2Ebss=2E Address both issues=2E
>
>-Kees
>
>Link: https://lore=2Ekernel=2Eorg/linux-hardening/CA+2EKTVLvc8hDZc+2Yhwmu=
s=3DdzOUG5E4gV7ayCbu0MPJTZzWkw@mail=2Egmail=2Ecom [1]
>
>Kees Cook (2):
>  x86: Increase brk randomness entropy on x86_64
>  binfmt_elf: Leave a gap between =2Ebss and brk
>
> arch/x86/kernel/process=2Ec | 5 ++++-
> fs/binfmt_elf=2Ec           | 3 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>

Why do we even have the brk, or perhaps more importantly, why do we use it=
? Is there any reason whatsoever why glibc uses brk instead of mmap to her =
heap memory?

I thought the base of the brk wasn't even known to userspace other than in=
 the form of the image end=2E=2E=2E