linux-kernel - Re: [PATCH v2 0/2] x86/boot: fix relying on link order

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]

Date:   Mon,  7 Nov 2022 13:55:28 +0100
From:   Alexander Lobakin <alexandr.lobakin@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     Alexander Lobakin <alexandr.lobakin@...el.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Tony Luck <tony.luck@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Masahiro Yamada <masahiroy@...nel.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] x86/boot: fix relying on link order

From: Alexander Lobakin <alexandr.lobakin@...el.com>
Date: Tue, 1 Nov 2022 17:15:27 +0100

> The series contains stuff I caught last week while working on some
> x86 code. It can be considered a material for fixes or for next,
> I'm okay with either, although leaning more towards fixes :P
> 
> Notes on patches:
> * 0001: I didn't put any "Fixes:" tag since it's not linear. The
>         lines changed with this patch came from the initial x86
>         KASLR series, but that unconditional jump to the kernel
>         beginning already was there. It goes at least from the set
>         that brought relocatable kernel support to x86, but this
>         is quite prehistoric already and might not look really
>         relatable. So up to you whether it needs any.
> * 0002: doesn't fix anything, except that having any files listed
>         in that whitelist already is an architecture bug :D And
>         it wouldn't be convenient to decouple it from #0001, but
>         up to you as well.
> 
> From v1[0]:
>  * collect the Tested-by tags (Jiri);
>  * don't add pathetic returns after noreturn error() (Jiri);
>  * debug-print the entry point offset via debug_putaddr() before
>    booting (Jiri);
>  * always have an empty line before return statements (Jiri). 
> 
> [0] https://lore.kernel.org/all/20221031151047.167288-1-alexandr.lobakin@intel.com
> 
> Alexander Lobakin (2):
>   x86/boot: robustify calling startup_{32,64}() from the decompressor
>     code
>   scripts/head-object-list: remove x86 from the list
> 
>  arch/x86/boot/compressed/head_32.S |  2 +-
>  arch/x86/boot/compressed/head_64.S |  2 +-
>  arch/x86/boot/compressed/misc.c    | 16 ++++++++++------
>  scripts/head-object-list.txt       |  6 ------
>  4 files changed, 12 insertions(+), 14 deletions(-)

Ping?

Also, I managed to remove .head.text at all from x86. Would it be
better to respin this series with the third patch or send a
follow-up later?

> 
> -- 
> 2.38.1

Thanks,
Olek