From owner-freebsd-current Tue Sep 1 19:57:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20314 for freebsd-current-outgoing; Tue, 1 Sep 1998 19:57:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20299 for ; Tue, 1 Sep 1998 19:57:19 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id MAA24042; Wed, 2 Sep 1998 12:56:17 +1000 Date: Wed, 2 Sep 1998 12:56:17 +1000 From: Bruce Evans Message-Id: <199809020256.MAA24042@godzilla.zeta.org.au> To: bde@zeta.org.au, jdp@polstra.com Subject: Re: ELF binaries size Cc: current@FreeBSD.ORG, reilly@zeta.org.au Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I think it implies that elf wastes a full page of memory (the space >> between the ':'s above) most of the time (unless the ':'s are on a >> page boundary), while aout only wastes an average of half a page >> (the space between the text ':' and the end of the page). > >But a.out has a repeat of the same situation at the juncture of data >and bss, and ELF does not. No it doesn't. The bss immediately follows the data. The data section is padded to 4K in the file for some reason. >> >> Is this a security problem? >> > >> >I don't think so. Do you? >> >> Maybe if text is supposed to be unreadable. The system would have >> to clear the part of the first data page before the ':' to prevent >> leakage. FreeBSD doesn't seem to do this. > >It's moot on the i386, if I remember correctly. Doesn't execute >permission imply read permission on the i386? Sort of. The access bit in segment descriptors controls writability for data descriptors and readability for code descriptors, so execute permission is completely independent from read permission at the segment level. However, we only support mapping the text section and the data section to the same base, so all text can be accessed via the data segment selector, so protection decays to page level where there is only a read-write bit. >Also, how does it enhance security to prevent a program from reading >its own text segment? If a program doesn't want to read its text >segment then it should simply ... not read it. :-) Perhaps a stack overflow exploit could change a write() arg on the stack to arrange for the text segment to be written to a user-readable file for further examination. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message