linux-kernel - Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only

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: <20140422140526.GK5904@bivouac.eciton.net>
Date:	Tue, 22 Apr 2014 15:05:26 +0100
From:	Leif Lindholm <leif.lindholm@...aro.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Rob Herring <robherring2@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linaro Patches <patches@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only

On Tue, Apr 22, 2014 at 02:08:29PM +0100, Grant Likely wrote:
> > I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here.
> 
> I completely agree.

OK. So do we keep this around on unaffected architectures in perpetuity?

Or can there be some cut-off date when the majority of DT-enabled
platforms can stop including this workaround which permits new incorrect
DTs to be implemented so long as they are incorrect in this particular
way?

> > Really, I would like to see quirks like this fixed up out of line from
> > the normal flow somewhat like how PCI quirks are handled. So in this
> > example, we would just add the missing property to the dtb for the
> > broken platform before doing the memory scan. That does then require
> > libfdt which is something I'm working on.
> 
> In fact, for Leif's purposes, I would rather have a flag when booting via
> UEFI, and make the kernel skip the memory node parsing if the UEFI
> memory map is available. Then the stub doesn't need to do any munging of
> the DTB at all.

The reason for me doing that is because we (including you) agreed at
the discussion held during LCU13 that this was the safest way of
preventing "mischief" like userland trying to read information from
/proc/device-tree...

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