> Date: Wed, 7 Jun 1995 22:20:03 -0700
> From: "Scott L. Burson" <gyro@zeta-soft.com>
> Reply-To: "Scott L. Burson" <gyro@zeta-soft.com>
> 
> >Number:         1125
> >Category:       kern
> >Synopsis:       `exec'ing ZMAGIC executables whose data size is not page-aligned
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       low
> >Responsible:    kern-bug-people (Kernel Bug People)
> >State:          open
> >Class:          sw-bug
> >Submitter-Id:   net
> >Arrival-Date:   Wed Jun  7 22:20:01 1995
> >Originator:     Scott L. Burson
> >Organization:
> 	ZETA-SOFT, Ltd.
> >Release:        NetBSD-current circa 5/20/95
> >Environment:
> 	NetBSD/sparc
> System: NetBSD ganesh.zeta-soft.com 1.0A NetBSD 1.0A (GANESH) #17: Wed Jun 7 20:52:09 PDT 1995 gyro@ganesh.zeta-soft.com:/usr/src/sys/arch/sparc/compile/GANESH sparc
> 
> 
> >Description:
> 
> I have some Franz Allegro Common Lisp executables I have been trying to run
> under NetBSD-sparc.  They wouldn't start up; the problem turned out to be that
> the data size in the a.out header was not page-aligned.  This bit in two ways:
> first, `vm_mmap' failed in an obscure manner (with ENOMEM) if `size' was not
> page-aligned.  I fixed this in the obvious way, and then the `vm_allocate'
> call in `vmcmd_map_zero' blew out during the mapping of the BSS segment,
> because it was trying to remap the first page of the segment (which was the
> partial page at the end of the data segment).  I fixed this by modifying
> `exec_aout_prep_zmagic' to be careful about this case.
> 
> An experienced kernel hacker should decide whether these are the right fixes.
> In particular, one might argue that while the fix to `vm_mmap' may as well be
> left in, as it doesn't look like it can do any harm, `exec_aout_prep_zmagic'
> should be page-aligning all addresses and sizes in advance.
> 
> >How-To-Repeat:
> 
> See above.

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.

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

Gordon


> >Fix:
> *** vm/vm_mmap.c.~1~	Fri Mar 10 04:01:29 1995
> --- vm/vm_mmap.c	Wed Jun  7 19:17:26 1995
> ***************
> *** 679,684 ****
> --- 679,685 ----
>   
>   	if (size == 0)
>   		return (0);
> + 	size = round_page(size);		/* Gyro@zeta-soft.com 6/7/95 19:17 */
>   
>   	/* The file offset must be page aligned. */
>   	if (foff & PAGE_MASK)
> *** kern/exec_aout.c.~1~	Mon Nov 21 14:45:32 1994
> --- kern/exec_aout.c	Wed Jun  7 20:40:03 1995
> ***************
> *** 139,146 ****
>   	    VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE);
>   
>   	/* set up command for bss segment */
>   	NEW_VMCMD(&epp->ep_vmcmds, vmcmd_map_zero, execp->a_bss,
> ! 	    epp->ep_daddr + execp->a_data, NULLVP, 0,
>   	    VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE);
>   
>   	return exec_aout_setup_stack(p, epp);
> --- 139,149 ----
>   	    VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE);
>   
>   	/* set up command for bss segment */
> + 	/* `round_page' call inserted by Gyro@zeta-soft.com 6/7/95 20:38
> + 	 * If `execp->a_data' is not page aligned, we must be careful not to
> + 	 * overlap the region mapped for the data segment. */
>   	NEW_VMCMD(&epp->ep_vmcmds, vmcmd_map_zero, execp->a_bss,
> ! 	    round_page(epp->ep_daddr + execp->a_data), NULLVP, 0,
>   	    VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE);
>   
>   	return exec_aout_setup_stack(p, epp);
> 
> >Audit-Trail:
> >Unformatted:
> 
> 
>