Date: Wed, 2 Sep 1998 01:37:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: reilly@zeta.org.au (Andrew Reilly) Cc: jdp@polstra.com, current@FreeBSD.ORG Subject: Re: ELF binaries size Message-ID: <199809020137.SAA13431@usr01.primenet.com> In-Reply-To: <19980902090645.A1965@reilly.home> from "Andrew Reilly" at Sep 2, 98 09:06:45 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809020137.SAA13431>