[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YXj4WbzoPfdOgBtQ@hirez.programming.kicks-ass.net>
Date: Wed, 27 Oct 2021 08:57:29 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <keescook@...omium.org>
Cc: Borislav Petkov <bp@...e.de>, Josh Poimboeuf <jpoimboe@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Kristen Carlson Accardi <kristen@...ux.intel.com>,
Tony Luck <tony.luck@...el.com>,
Alexander Lobakin <alexandr.lobakin@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Arnd Bergmann <arnd@...db.de>, Joerg Roedel <jroedel@...e.de>,
Arvind Sankar <nivedita@...m.mit.edu>,
Jing Yangyang <jing.yangyang@....com.cn>,
Abaci Robot <abaci@...ux.alibaba.com>,
Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Andrey Konovalov <andreyknvl@...il.com>,
Miroslav Benes <mbenes@...e.cz>,
"H. Nikolaus Schaller" <hns@...delico.com>,
Fangrui Song <maskray@...gle.com>,
linux-kernel@...r.kernel.org, x86@...nel.org,
linux-arch@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH 0/4] x86: Various clean-ups in support of FGKASLR
On Wed, Oct 13, 2021 at 10:57:38AM -0700, Kees Cook wrote:
> Kees Cook (2):
> x86/boot: Allow a "silent" kaslr random byte fetch
> x86/boot/compressed: Avoid duplicate malloc() implementations
>
> Kristen Carlson Accardi (2):
> x86/tools/relocs: Support >64K section headers
> vmlinux.lds.h: Have ORC lookup cover entire _etext - _stext
>
> arch/x86/boot/compressed/kaslr.c | 4 --
> arch/x86/boot/compressed/misc.c | 3 +
> arch/x86/boot/compressed/misc.h | 2 +
> arch/x86/lib/kaslr.c | 18 ++++--
> arch/x86/tools/relocs.c | 103 ++++++++++++++++++++++--------
> include/asm-generic/vmlinux.lds.h | 3 +-
> include/linux/decompress/mm.h | 12 +++-
> 7 files changed, 107 insertions(+), 38 deletions(-)
Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Boris, these are indeed all improvements to the status quo, irrespective
of future FGKASLR work. Do you want to take them, or should I stick them
in x86/core ?
Powered by blists - more mailing lists