From owner-freebsd-current Tue Sep 1 18:39:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA09309 for freebsd-current-outgoing; Tue, 1 Sep 1998 18:39:06 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA09299 for ; Tue, 1 Sep 1998 18:39:02 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA26448; Tue, 1 Sep 1998 18:38:01 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd026377; Tue Sep 1 18:37:51 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA13431; Tue, 1 Sep 1998 18:37:48 -0700 (MST) From: Terry Lambert Message-Id: <199809020137.SAA13431@usr01.primenet.com> Subject: Re: ELF binaries size To: reilly@zeta.org.au (Andrew Reilly) Date: Wed, 2 Sep 1998 01:37:48 +0000 (GMT) Cc: jdp@polstra.com, current@FreeBSD.ORG In-Reply-To: <19980902090645.A1965@reilly.home> from "Andrew Reilly" at Sep 2, 98 09:06:45 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, Sep 01, 1998 at 10:19:18AM -0700, John Polstra wrote: > > Yes. That's because a.out rounds the text and data segments up to > > page boundaries, but ELF does not. > > Does that mean that the last page in a text segment is treated > differently (wrt vm paging) than the rest of the image, or is > garbage loaded plast the end, along with the last page? Is this > a security problem? Text pages are mapped read-only anyway. This is not a security problem. Effectively, what should happen is that if there is an odd boundary, the last text page will include part of the data page following it, mapped read only, and the first data page will include the last text page, mapped copy-on-write. This is worst case. >From reading the sources, I think this does not happen (it would be hard to make the vnode pager function in the presence of a unified VM and buffer cache, if this were going on ;-)), and the sections are loaded starting(/ending) on page boundaries, only for their length. This saves you from the relocation overhead of reading on partial page boundaries, for a page (start an MS-DOS FS on an odd 512b boundary to see why this is a bad idea for every fourth block, since it spans a page boundary). What this means is that it takes the same space in core, but less space on disk, and that the padding is implied, and an odd boundary is seen as a negative offset (i.e., the first part of the first data page is mapped, but not valid). Given where the pages come from, this should not expose "old data" in the gaps. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message