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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ