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

Powered by blists - more mailing lists