linux-kernel - Introduce userspace interface for Firmware-provided memory map

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: <1213977420-1555-1-git-send-email-bwalle@suse.de>
Date:	Fri, 20 Jun 2008 17:56:57 +0200
From:	Bernhard Walle <bwalle@...e.de>
To:	kexec@...ts.infradead.org
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org, vgoyal@...hat.com,
	Bernhard Walle <bwalle@...e.de>
Subject: Introduce userspace interface for Firmware-provided memory map

This patch (as request for comments) introduces a new userspace interface
/proc/firmware_mem that provides the unfiltered view of the BIOS on
memory configuration. That's usable for two reasons:

 1) Debugging (yes, the E820 memory is printed in kernel ring buffer, but that's
    not the case for all platforms, on IA64 you have to enable some magic define
    to print the EFI memory map, for example),
 
 2) Kexec. When the user or the system uses a special command line to modify the
    memory configuration, kexec still needs a method to get the original memory
    map.  While the filtered view is useful for generating ELF core headers for
    crashdumps, the unfiltered view is necessary to boot the next kernel without
    the "limitations" the original kernel has.

We had the discussion to add iomem_used on kexec mailing list. However, I think
it's better to let /proc/iomem represent the *filtered* (i.e. "used") view of
the I/O resources and introduce a new interface for the *unfiltered* view.
There are two reasons:

 1) On i386 (the oldest architectures), /proc/iomem always represented the
    *filtered* view (i.e. "mem" parameter was also visible in /proc/iomem).
    I think we should not change the semantics of an interface without a reason.
 
 2) /proc/iomem_used would it make necessary to duplicate all registration between
    /proc/iomem and /proc/iomem_used. Because currently the resource root
    is exported and used everywhere in the kernel source, that would make
    changes of the whole resource infrastructure necessary if code duplication
    should be avoided.

Maybe you think that /proc/firmware_mem is not the right place to export that.
I don't know, I also don't care that much about the naming or the way to export
that. So, please advise me if you agree that it's ok for kexec to export an
unfiltered view of the memory map.

The patch has been tested on i386 and x86_64.



Signed-off-by: Bernhard Walle <bwalle@...e.de>



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