Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Sep 1998 12:56:17 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, jdp@polstra.com
Cc:        current@FreeBSD.ORG, reilly@zeta.org.au
Subject:   Re: ELF binaries size
Message-ID:  <199809020256.MAA24042@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809020256.MAA24042>