linux-kernel - Re: x86_32: CONFIG_PHYSICAL

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] [day] [month] [year] [list]

Message-ID: <87ft45spzi.fsf@nanos.tec.linutronix.de>
Date:   Wed, 16 Dec 2020 16:57:37 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Randy Dunlap <rdunlap@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>
Subject: Re: x86_32: CONFIG_PHYSICAL_START problem

On Sat, Dec 12 2020 at 22:29, Randy Dunlap wrote:
> Little to my knowledge, this came up with
> CONFIG_PHYSICAL_START=0x81000000
...
> I tracked it down to this large value of CONFIG_PHYSICAL_START
> and changed it back to its default value, then the kernel
> built with no problems.
>
> So far I haven't been able to track the chain of values/changes
> that involve PHYSICAL_START, __PAGE_OFFSET, LOAD_OFFSET, etc.

It's convoluted :)

> Anyway, I would like to see PHYSICAL_START limited to some
> acceptable range of values in arch/x86/Kconfig,

Its the combination of CONFIG_PHYSICAL_START and CONFIG_PAGE_OFFSET so
having checks in Kconfig is going to be a challenge.

> or at a minimum, a little bit better error message coming
> from arch/x86/kernel/vmlinux.lds.S:
>
> . = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
> 	   "kernel image bigger than KERNEL_IMAGE_SIZE");
>
> so maybe:
>
> . = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
> 	   "kernel image bigger than KERNEL_IMAGE_SIZE or load address is too large");
> (or start address)

Some reasonable error message is definitely due, but we probably can
catch that at the compile stage already once we computed the combined
values. Then we can sanity check those for resonable ranges.

Thanks,

        tglx