Subject: kern/1125: `exec'ing ZMAGIC executables whose data size is not page-aligned
To: None <gwr@mc.com>
From: Scott L. Burson <gyro@zeta-soft.com>
List: netbsd-bugs
Date: 06/08/1995 11:33:32
   From: "Gordon W. Ross" <gwr@mc.com>
   Date: Thu, 8 Jun 95 09:31:28 EDT

   I think exec_aout_prep_zmagic could be considered correct to reject
   a ZMAGIC executable with non page-aligned boundaries.  That said, it
   seems harmless to make it correct misaligned boundaries as you did.

Hmm, well, there is a subtle difference between what the SunOS and the NetBSD
`a.out' man pages say about this.  The NetBSD version:


               ZMAGIC  The kernel loads individual pages on demand from the
                       binary.  The header, text segment and data segment are
                       all padded by the link editor to a multiple of the page
                       size.  Pages that the kernel loads from the text seg-
                       ment are read-only, while pages from the data segment
                       are writable.

     [...]

     a_bss     Contains the number of bytes in the `bss segment' and is used
               by the kernel to set the initial break (brk(2))  after the data
               segment.  The kernel loads the program so that this amount of
               writable memory appears to follow the data segment and initial-
               ly reads as zeroes.

The SunOS version:

                    ZMAGIC      A  page-aligned  text  executable
                                image.   the  data segment begins
                                at  the  first  segment  boundary
                                following  the  text segment, and
                                the text segment is not  writable
                                by  the  program.   The  text and
                                data sizes are both multiples  of
                                the  page  size, and the pages of
                                the file will be brought into the
                                running  image as needed, and not
                                pre-loaded as with the other for-
                                mats.  This is the default format
                                produced by ld(1).

     [...]

     a_bss          The size of the  "uninitialized"  portion  of
                    the  data segment, in bytes.  This portion is
                    actually initialized to zero.  The zeroes are
                    not  stored  in  the  a.out file; the data in
                    this portion of the data  segment  is  zeroed
                    out when it is loaded.

The SunOS language encourages an interpretation of the BSS area as being part
of the data segment, and therefore suggests that only the *sum* of the data
size and BSS size need be page-aligned (which, in fact, it is in the
executable in question).  The NetBSD language, on the other hand, encourages
an interpretation of the BSS area as a separate segment (though for clarity,
the ZMAGIC paragraph should add it to its list of padded segments).

So from NetBSD's own point of view you are right, but for SunOS compatibility
it is evidently necessary to take the more generous interpretation.

It occurs to me that what I should really do is zero out the unused portion of
the partial page at the end of the data region, just in case this has not been
done in the executable, since the BSS region is supposed to contains zeros.
But I am a kernel novice and don't know how to modify user memory.

   The unaligned boundaries probably come from a defective undump().

The Franz Allegro Common Lisp executables have a built-in dumper that makes an
executable copy of the current state of the workspace.

-- Scott