linux-kernel - Regarding CONFIG_PHYSICAL_START=16MB in linux-next tree

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

Date:	Thu, 12 Jun 2008 10:40:29 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>
Cc:	sfr@...b.auug.org.au, tglx@...utronix.de
Subject: Regarding CONFIG_PHYSICAL_START=16MB in linux-next tree

Hi Ingo,

I just noticed that configs/i386_defconfig now contains the
CONFIG_PHYSICAL_START=0x1000000 (16MB) instead of 1MB.

This change has been introduced by following commit in linux-next tree.

commit 5cb04df8d3f03e37a19f2502591a84156be71772
Author: Ingo Molnar <mingo@...e.hu>
Date:   Sun May 4 19:49:04 2008 +0200

    x86: defconfig updates

    refresh 32-bit defconfig too, and update the 64-bit configs as well,
    the defconfig should be much more useful by default, so most of the
    updates are the enabling of various options.

I think this will break kdump on i386. Now kernel will be compiled for
physical address 16MB but effectively it will run from physical address
2MB. Boot loader will load kernel at 1MB and due to alignment restriction
of 2MB, kernel will move itself to 2MB address.

Now run time virtual addresses for kernel symbols will be different from
compile time virtual address and gdb and crash utilities will not be
able to open kernel dumps.

What's the reason that we want to compile the kernel for 16MB address? I
guess, probably the intention must have been that we want to run kernel
from 16MB physical address by default so that lower memory addresses are
available for DMA etc?

If that's the case, we probably also need to change
CONFIG_PHYSICAL_ALIGN=16MB, so that first kernel is compiled for 16MB and
it runs from 16MB address and kdump is not broken.

The side effect of this will be when same kernel is loaded in reserved
memory for kdump operation, it will look for 16MB aligned addresses as
compared to 2MB. Asking for 16MB aligned addresses as compared to 2MB
aligned addresses is more strict a requirement when second kernel is
running in a constrained memory environment.

If that's not the intention, then CONFIG_PHYSICAL_START=1MB should be good.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/