linux-kernel - Re: [RFC 0/3] extend kexec_file

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: <20160712145010.GA8447@leverpostej>
Date:	Tue, 12 Jul 2016 15:50:10 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org, bhe@...hat.com,
	linuxppc-dev@...ts.ozlabs.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	AKASHI Takahiro <takahiro.akashi@...aro.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	bauerman@...ux.vnet.ibm.com, dyoung@...hat.com,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [RFC 0/3] extend kexec_file_load system call

On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote:
> On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote:
> > > 
> > > On Open Firmware, the DT is extracted from running firmware and copied
> > > into dynamically allocated data structures. After a kexec, the runtime
> > > interface to the firmware is not available, so the flattened DT format
> > > was created as a way to pass the same data in a binary blob to the new
> > > kernel in a format that can be read from the kernel by walking the
> > > directories in /proc/device-tree/*.
> > 
> > So this DT is available inside kernel and running kernel can still
> > retrieve it and pass it to second kernel?
> 
> The kernel only uses the flattened DT blob at boot time and converts
> it into the runtime data structures (struct device_node). The original
> dtb is typically overwritten later.

On arm64 we deliberately preserved the DTB, so we can take that and
build a new DTB from that kernel-side.

> > > - we typically ship devicetree sources for embedded machines with the
> > >   kernel sources. As more hardware of the system gets enabled, the
> > >   devicetree gains extra nodes and properties that describe the hardware
> > >   more completely, so we need to use the latest DT blob to use all
> > >   the drivers
> > > 
> > > - in some cases, kernels will fail to boot at all with an older version
> > >   of the DT, or fail to use the devices that were working on the
> > >   earlier kernel. This is usually considered a bug, but it's not rare
> > > 
> > > - In some cases, the kernel can update its DT at runtime, and the new
> > >   settings are expected to be available in the new kernel too, though
> > >   there are cases where you actually don't want the modified contents.
> > 
> > I am assuming that modified DT and unmodifed one both are accessible to
> > kernel. And if user space can make decisions which modfied fields to use
> > for new kernels and which ones not, then same can be done in kernel too?
> 
> The unmodified DT can typically be found on disk next to the kernel binary.
> The option you have is to either read it from /proc/devicetree or to
> read it from from /boot/*.dtb.

/proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived
from the raw DTB (which is exposed at /sys/firmware/fdt).

The blob that was handed to the kernel at boot time is exposed at
/sys/firmware/fdt.

Thanks,
Mark.