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