linux-kernel - Re: [patch 2/2] x86/boot/32: Disable stackprotector and tracing for mk_early_pgtbl

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: <ZPj6gxSUc8SLzpLQ@gmail.com>
Date:   Thu, 7 Sep 2023 00:17:39 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>, x86@...nel.org,
        Ashok Raj <ashok.raj@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Fenghua Yu <fenghua.yu@...el.com>, Peter Anvin <hpa@...or.com>
Subject: Re: [patch 2/2] x86/boot/32: Disable stackprotector and tracing for
 mk_early_pgtbl_32()


* Thomas Gleixner <tglx@...utronix.de> wrote:

> Stackprotector cannot work before paging is enabled. The read from the per
> CPU variable __stack_chk_guard is always accessing the virtual address
> either directly on UP or via FS on SMP. In physical address mode this
> results in an access to memory above 3GB.
> 
> So this works by chance as the hardware returns the same value when there
> is no RAM at this physical address. When there is RAM populated above 3G
> then the read is by chance the same as nothing changes that memory during
> the very early boot stage.
> 
> Stop relying on pure luck and disable the stack protector for the only C
> function which is called during early boot before paging is enabled.
> 
> Remove function tracing from the whole source file as there is no way to
> trace this at all, but in case of CONFIG_DYNAMIC_FTRACE=n
> mk_early_pgtbl_32() would access global function tracer variables in
> physcial address mode which again might work by chance.
> 
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> ---
>  arch/x86/kernel/Makefile |    1 +
>  arch/x86/kernel/head32.c |    3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Ingo Molnar <mingo@...nel.org>

Thanks,

	Ingo