linux-kernel - Re: [PATCH] Limit E820 map and /proc/iomem for mem parameter on x86-64

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

Message-ID: <20080611153901.GD6450@redhat.com>
Date:	Wed, 11 Jun 2008 11:39:01 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc:	Bernhard Walle <bwalle@...e.de>
Subject: Re: [PATCH] Limit E820 map and /proc/iomem for mem parameter on
	x86-64

On Tue, Jun 10, 2008 at 11:53:25PM +0200, Bernhard Walle wrote:
> This patch tries to unify the behaviour of i386 and x86-64 when parsing
> the memory (mem/memmap) parameter of the kernel command line:
> 
> On i386, the view was limited (i.e. the actual view was presented).
> On x86-64, the view was full (i.e. the BIOS view was presented).
> 
> This patch moves the limit_regions() function and the print_memory_map()
> function to a new file e820.c, shared between the two x86 flavours. Then
> it adds calls to limit_regions() in 64 bit code.
> 
> I gave the patch a bit testing. However, it's not for merging, it's just
> to get early feedback to see if that goes into the right direction.
> 
> 

I would like to have consistent behavior of /proc/iomem across i386
and x86_64, so this sounds like right direction to me.

Also I would like to have another interface (say /proc/iomem_kernel)which
actually gets modified based on the user specified options. So effectively we
can have both the views. BIOS view and user defined view.

As discussed on kexec mailing list, it helps kexec and kdump operation. 
In the case of kexec, we want to know the actual resources present in 
the system so that new kernel can see it (Irrespective of the fact
what first kernel was actually using).

In case of kdump, we want to see truncated view so that we don't end
up capturing the contents of memory not being used by kernel.

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/