linux-kernel - Re: N900 v3.19-rc5 arm atags_to

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: <20150127175359.GE11502@n2100.arm.linux.org.uk>
Date:	Tue, 27 Jan 2015 17:53:59 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	Pavel Machek <pavel@....cz>, Tony Lindgren <tony@...mide.com>,
	Pali Rohár <pali.rohar@...il.com>,
	linux-omap <linux-omap@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Sebastian Reichel <sre@...nel.org>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Laura Abbott <lauraa@...eaurora.org>
Subject: Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken

On Tue, Jan 27, 2015 at 10:16:24AM -0500, Nicolas Pitre wrote:
> On Tue, 27 Jan 2015, Pavel Machek wrote:
> > (Note, that in 3.19 dts for n900 got too big, so we are actually
> > triggering old bugs. That means that this is a regression fix, and
> > should go in ASAP).
> 
> It is queued here:
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8294/1

Irrespective of that patch, I commented on another thread (about adding
the serial number to DT):

| How about something a little more radical.
| 
| Rather than trying to squeeze various ATAGs into DT, why don't we add a
| standard ATAG to contain the DT and pass that through into the kernel.
| This is IMHO how we _should_ have done the ATAG compatibility from the
| start.
| 
| That means we could get rid of most of the libfdt in the decompressor,
| and instead resolve the differences in the kernel.

That would allow us to get rid of all the FDT compatibility code in the
decompressor, and when we encounter these special ATAGs, we can deal with
them in the kernel instead of having to mess around with the DT.  I'd
also assume (although I haven't checked) that it would be much easier to
add additional DT properties in the kernel environment, rather than in
the rather restrictive decompressor environment.

We'd need to be careful about how we deal with the atags vs DT.  I'd
suggest (as above) that we have a tag which points at the DT in
physical memory, and its size, and pre-scan the atag list for that.
When we find it, we kick off the DT based stuff as we would normally
do, and follow it with a parse of the atags.  This would cause the
atags to override whatever is in the DT, which afaics is the behaviour
that we actually want.

We could augment that with code to update DT too so that we can export
just the DT based information to kexec'd kernels.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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/