linux-kernel - Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

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: <20151127132722.GA30871@n2100.arm.linux.org.uk>
Date:	Fri, 27 Nov 2015 13:27:23 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Pali Rohár <pali.rohar@...il.com>
Cc:	Frank Rowand <frowand.list@...il.com>,
	Tony Lindgren <tony@...mide.com>,
	Arnd Bergmann <arnd@...db.de>, Pavel Machek <pavel@....cz>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Laura Abbott <lauraa@...eaurora.org>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robherring2@...il.com>,
	Will Deacon <will.deacon@....com>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Sebastian Reichel <sre@...ian.org>,
	Andreas Färber <afaerber@...e.de>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org
Subject: Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT
 "/chosen/linux,atags" entry

On Thu, Nov 26, 2015 at 10:07:39AM +0100, Pali Rohár wrote:
> On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote:
> > > Or populate /proc/atags only for the ones that need it from machine
> > > specific init_early?
> > 
> > This is circling back to the first comment from Russell King where
> > he suggested a legacy file for the N900 which calls save_atags():
> > 
> >     Are the ATAGs at a fixed address on the N900?  Can that be handled in
> >     some kind of legacy file for the N900 which calls save_atags() on it, so
> >     we don't end up introducing yet more stuff that we have to maintain into
> >     the distant future?  If not, what about copying a known working atag
> >     structure into a legacy file for the N900?
> > 
> > It seems to me that patches 1, 2, 4, and 5 could be replaced by this
> > approach.
> 
> Hi Frank, in this case I will ask my question again: It is possible to
> read atags from that legacy file. And if yes how? I was not thinking
> about this approach because somebody in past wrote that this is not
> possible...

It is possible to redirect any program to open any other file.  You can
do it via a LD preload, and intercepting the open(), and possibly the
read() calls if you want to do something more fancy.  The down-side is
that you have to arrange for the preloaded object to be used by the
linker, and the additional overhead it places on the intercepted
functions.

Eg,

openatags.c:

#define open libc_open
#include <fcntl.h>
#undef open
#include <string.h>

int open(const char *pathname, int flags, mode_t mode)
{
        static int (*old_open)(const char *pathname, int flags, mode_t mode);

        if (strcmp(pathname, "/proc/atags") == 0)
		pathname = "/tmp/my-atags";

        if (!old_open)
                old_open = dlsym(RTLD_NEXT, "open");

        return old_open(pathname, flags, mode);
}

Build the above (untested) with:
gcc -O2 -o openatags.o -c openatags.c
gcc -shared -o openatags.so openatags.o -ldl

Now, when running one of these programs, you can test it with:
LD_PRELOAD=openatags.so /name/of/program

You could also list the full pathname to openatags.so in /etc/ld.so.preload,
but test it first, because it will always be used by the linker in that
case, and you wouldn't want normal commands to misbehave.

Note that putting it in /etc/ld.so.preload will also have the effect that
cat /proc/atags will also get redirected to /tmp/my-atags too.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps 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/