Date: Thu, 3 Sep 1998 01:30:56 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: ELF binaries size Message-ID: <199809030130.SAA03730@usr07.primenet.com> In-Reply-To: <19980902145445.24306@follo.net> from "Eivind Eklund" at Sep 2, 98 02:54:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce answered the other; I'll answer this one: > Or am I missing something that should be obvious here? For a system to be secure, you must not permit code to be written to by the process, only data. The only way you can do this is to map the page "read-only". If the code and the data do not butt up to each other on an even page boundary, using the same physical page would be wrong. This is because data needs the page to be mapped "copy-on-write". You can't have both in the same page because the hardware only enforces protections on full pages. [ Technically, you could do this; you would map the page and set an attribute such that when you got the fault, you would handle the fault differently based on the page it wanted to write. This is how kernel read protection is implemented for the 386, which does not support the "write protect bit". Note that this would be slow as molasses, and would probably not coexist peacably with the F00F bug workaround.] So you map the same page twice. The disk space savings come from the fact that ELF binaraies, unlike a.out binaries, do *not* pad the code section out to a page boundary to facilitate mapping, relying on the loader to map the page twice. But the header information in the ELF header states that the data is in the middle of a page, such that the page boundary following the last of the text is also the page boundary at the *end* of the first page of data. In other words, you start with a partial page of data, and the region before the data is either text, or zeroed (preferrably, it is zeroed). 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?199809030130.SAA03730>