linux-kernel - Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

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: <20070920031807.GA31263@linux-sh.org>
Date:	Thu, 20 Sep 2007 12:18:07 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	David McCullough <David_Mccullough@...urecomputing.com>
Cc:	Robin Getz <rgetz@...ckfin.uclinux.org>,
	uclinux-dist-devel@...ckfin.uclinux.org, bryan.wu@...log.com,
	Bernd Schmidt <bernd.schmidt@...log.com>,
	Greg Ungerer <gerg@...pgear.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	ysato@...rs.sourceforge.jp, miles@....nec.co.jp,
	linux-m32r@...linux-m32r.org
Subject: Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

On Thu, Sep 20, 2007 at 11:55:25AM +1000, David McCullough wrote:
> Jivin Robin Getz lays it down ...
> > On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
> > > This just adds minimum support for the Blackfin relocations,
> > > since we don't have enough space in each reloc. The idea
> > > is to store a value with one relocation so that subsequent ones can
> > > access it.
> > 
> > Adding the other appropriate maintainers. for h8, m32r, sh and v850.
> 
> Looks fine to me,  obviously impacts the existing arches very little.
> Can't see why it shouldn't get included,
> 
I find it a bit disconcerting that blackfin already depends on this
in-tree without there being any earlier discussion on making these
changes.

> > >  	 */
> > >  	if (rev > OLD_FLAT_VERSION) {
> > > +		unsigned long persistent = 0;
> > >  		for (i=0; i < relocs; i++) {
> > >  			unsigned long addr, relval;
> > >  
> > > @@ -749,6 +750,8 @@ static int load_flat_file(struct linux_binprm * bprm,
> > >  			   relocated (of course, the address has to be
> > >  			   relocated first).  */
> > >  			relval = ntohl(reloc[i]);
> > > +			if (flat_set_persistent (relval, &persistent))
> > > +				continue;
> > >  			addr = flat_get_relocate_addr(relval);
> > >  			rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
> > >  			if (rp == (unsigned long *)RELOC_FAILED) {

I don't much care for this API. It's shuffling around a temporary
variable for the architecture code that's set for certain relocations
that are otherwise unhandled.

Since all the architecture is interested in is the relval that has
associated "persistent" data encoded in it, why don't we just have a stub
to give the architecture a chance to validate the relval before the
flat_get_relocate_addr() and move this stuff there instead? ie, blackfin
takes this out-of-line and manages its persistent value there.

> > > @@ -757,7 +760,7 @@ static int load_flat_file(struct linux_binprm * bprm,
> > >  			}
> > >  
> > >  			/* Get the pointer's value.  */
> > > -			addr = flat_get_addr_from_rp(rp, relval, flags);
> > > +			addr = flat_get_addr_from_rp(rp, relval, flags, &persistent);
There's no reason for this to be a pointer. The current in-tree blackfin
code doesn't change this value, and if you have patches that are doing
that, this is even more reason to bury this kind of silliness in your
architecture code.

load_flat_file() is ugly enough without dumping more architecture
callback abuses in it.
-
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/