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

Message-ID: <82a78e8c-b4e6-3eb7-01e3-286bcbb869e3@infradead.org>
Date:   Sat, 12 Dec 2020 22:29:13 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>
Subject: x86_32: CONFIG_PHYSICAL_START problem

background:

I was trying to debug a MIPS build error, but it wasn't MIPS-specific,
so I did this, using the MIPS .config file:

make ARCH=i386 O=xx32 olddefconfig

Little to my knowledge, this came up with
CONFIG_PHYSICAL_START=0x81000000

Then I built the i386 kernel, and got this message:
ld: kernel image bigger than KERNEL_IMAGE_SIZE

so I promptly changed many =y drivers etc. to =m
and still got the same ld error message.

Well, it must be something else, he said.

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.

Anyway, I would like to see PHYSICAL_START limited to some
acceptable range of values in arch/x86/Kconfig,
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)

Comments?

thanks.
-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@...radead.org>