NetBSD Problem Report #13435

Received: (qmail 3191 invoked from network); 11 Jul 2001 11:32:00 -0000
Message-Id: <20010711113505.32B5D1110F@www.netbsd.org>
Date: Wed, 11 Jul 2001 04:35:05 -0700 (PDT)
From: nigel@ind.tansu.com.au
Sender: nobody@netbsd.org
Reply-To: nigel@ind.tansu.com.au
To: gnats-bugs@gnats.netbsd.org
Subject: libsa loadfile() loads binary or kernel at wrong address
X-Send-Pr-Version: www-1.0

>Number:         13435
>Category:       kern
>Synopsis:       libsa loadfile() loads binary or kernel at wrong address
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 11 11:33:00 +0000 2001
>Closed-Date:    
>Last-Modified:  Sat May 22 05:20:01 +0000 2021
>Originator:     Nigel Pearson
>Release:        None
>Organization:
Telstra NW-D
>Environment:
Not applicable
>Description:
	Revision 1.10 of loadfile.c, compiled into Mac68k Booter program.
When loading a standard mac68k kernel with a non-zero entry point
(e.g. a_entry = 0x2e00), the kernel image is being loaded offset by
the entry. (i.e. 0x0 thru 0x2e00 is unused, entry point is now 0x5c00).


	Am correcting problem by applying this hack in loadfile():

i = hdr.aout.a_entry;hdr.aout.a_entry = 0;

rval = aout_exec(fd, &hdr.aout, marks, flags);

marks[MARK_ENTRY] += i;
>How-To-Repeat:
Can probably e-mail you a test program if unable to reproduce.
>Fix:
	Discussion: aout_exec(), for some reason I cannot fathom, sets minp
and maxp to ALIGNENTRY(entry). This means that header or text section
will _always_ be loaded at marks[MARK_START] + entry. Look at the code:

aout_exec(fd, x, marks, flags)...
	u_long entry = x->a_entry;...
	paddr_t offset = marks[MARK_START];...
	minp = maxp = ALIGNENTRY(entry);
...
	if (flags & LOAD_TEXT) {		PROGRESS(("%ld", x->a_text));		if (READ(fd, maxp, x->a_text - sub) != x->a_text - sub) {
...



	Suspect we should do :

% diff -u loadfile.c loadfile-hack.c  
--- loadfile.c  Mon Jul  9 12:18:19 2001
+++ loadfile-hack.c     Wed Jul 11 21:34:57 2001
@@ -446,9 +446,8 @@
        u_long *marks;
        int flags;
 {
-       u_long entry = x->a_entry;
        paddr_t aoutp = 0;
-       paddr_t minp, maxp;
+       paddr_t minp, maxp = 0;
        int cc;
        paddr_t offset = marks[MARK_START];
        u_long magic = N_GETMAGIC(*x);
@@ -460,8 +459,6 @@
        else
                sub = sizeof(*x);

-       minp = maxp = ALIGNENTRY(entry);
-
        if (lseek(fd, sizeof(*x), SEEK_SET) == -1)  {
                WARN(("lseek text"));
                return 1;
@@ -618,7 +615,7 @@
        }

        marks[MARK_START] = LOADADDR(minp);
-       marks[MARK_ENTRY] = LOADADDR(entry);
+       marks[MARK_ENTRY] = LOADADDR(x->a_entry);
        marks[MARK_NSYM] = x->a_syms;
        marks[MARK_SYM] = LOADADDR(aoutp);
        marks[MARK_END] = LOADADDR(maxp);
%
>Release-Note:
>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/13435: libsa loadfile() loads binary or kernel at wrong
 address
Date: Sat, 22 May 2021 01:03:49 +0000

 The issue still remains (the code in libsa/loadfile_aout.c assumes
 that the entry point is at the beginning of the image text) but the
 enclosed patch isn't the right answer; among other things, it doesn't
 initialize "minp".

 I'm not sure what the right thing to do is, because while my memory of
 how a.out bins is very rusty I'm pretty sure that at least for some
 variants assuming the image begins at address 0 is also incorrect.

 however, I'm also wondering why we still have code for loading a.out
 kernel images; maybe the right thing to do is remove it and close the
 PR :-)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 nigel@ind.tansu.com.au
Subject: Re: kern/13435: libsa loadfile() loads binary or kernel at wrong
 address
Date: Fri, 21 May 2021 18:15:52 -0700

 > On May 21, 2021, at 6:05 PM, David Holland <dholland-bugs@netbsd.org> =
 wrote:
 >=20
 > however, I'm also wondering why we still have code for loading a.out
 > kernel images; maybe the right thing to do is remove it and close the
 > PR :-)

 There are legacy platforms that still, due to firmware restrictions, =
 require loading of a.out.  At least for those platforms, it might still =
 be handy to be able to load a single kernel image either from a boot =
 loader or from the firmware directly.

 -- thorpej

From: matthew green <mrg@eterna.com.au>
To: Jason Thorpe <thorpej@me.com>
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, nigel@ind.tansu.com.au,
    gnats-bugs@netbsd.org
Subject: re: kern/13435: libsa loadfile() loads binary or kernel at wrong address
Date: Sat, 22 May 2021 15:17:01 +1000

 Jason Thorpe writes:
 > =

 > > On May 21, 2021, at 6:05 PM, David Holland <dholland-bugs@netbsd.org> =
 wrote:
 > >
 > > however, I'm also wondering why we still have code for loading a.out
 > > kernel images; maybe the right thing to do is remove it and close the
 > > PR :-)
 >
 > There are legacy platforms that still, due to firmware restrictions, =

 > require loading of a.out.  At least for those platforms, it might still =

 > be handy to be able to load a single kernel image either from a boot =

 > loader or from the firmware directly.

 infact, if memory serves, there's one platform you were unable
 to create an ofwboot for, and we're stuck with a.out kernels
 loaded by the firmware.  :-)

 of course, if we could figure out that issue and switch shark
 to ofwboot + elf kernel that woudl be awesome.


 .mrg.

>Unformatted:

Home	PR Database Search