Paco Hope wrote:
> Here's my baseline assumption. If I'm wrong here, I'm only going to get
> wronger as I go:
> If I have two different programs that both use a shared library,
> libfoo.so, the system memory maps the object code they need into the
> processes' address spaces. There's only one copy of libfoo.so in memory,
> and the two processes each have handles into it (or maybe just to the
> pieces of it that they use?).
There's one copy of the code pages. There's one copy of the unmodified
data pages. Everything is mapped COW (copy-on-write). If there are
changes to data pages or a jump table fixup, etc., each process will
gt it's own copy of the modified pages (and *only* the modified pages!).
> Step 2 of my question. This gets closer to my real query:
> Ok now consider a hard link (not a symlink) from libfoo.so to libbar.so.
> One inode, two directory entries. Consider my two programs again, one
> linked against libfoo.so and the other linked against libbar.so. When
> they run, how many copies of the lib{foo,bar}.so object code are in RAM?
> My current hypothesis is 1. Isn't it mmapped off the disk? The inode
> matters, not the file name, right? With me so far? Great.
Actually, it's the vnode that matters, not the inode or the file
name. The vnode is used as backing store, through the vnode pager,
for the pages in each process. For each file, there is only one
vnode, and one vmobject_t, corresponding to it. If data or code
pages are modified, as before, since they are COW, what happens is
that each process gets its own pmap entries to copies of the pages,
and those copies are backed using swap as backing store (swap pager).
The reason I make this distinction is that it probably would not
help you to use loopback mounts, which is a problem for you if you
wish to maintain priviledge seperation.
> Now consider jail(8). Let's say I have two jail environments (If you
> think I mean chroot here, go read jail(8), it's not the same. I'm
> assuming folks on hackers know jail.). To make my first jail, I make a
> copy of the FreeBSD stuff that my jail needs. To make the second jail, I
> create a directory hiearachy, but I *hard link* all the binaries and
> libraries and stuff to the same inodes that the first jail uses.
[ ... ]
> Now the $64K question: How many instances of, for example, the libz.so.2
> object code are in memory? Did my use of jail(8) make any difference? My
> intuition is that only one copy of the code is in memory for the same
> reason as in step 2 above. This is the real question I am interested in.
If they are hard links, they get the same vnodes. Therefore they
get the same vmobject_t's. Therefore there is a single copy in
memory, until pages are modified, at which point the modified
pages aren't shared, but the rest of the file remains shared.
> I'm also interested in a broader question. Consider instantiating many
> jails this way--say 50 or 100 all hard linked to the same base set of
> files. Can we characterize in some general hand-waving way how much
> memory (RAM) I would save doing it this way as opposed to the naive way
> of 50 or 100 copies of the files? I am assuming that if I have 50 copies
> of the files and I run 50 processes in 50 jails, then I will use more
> RAM than if I had 50 hard links to the same inode and ran 50 processes
> in 50 jails from that one inode. The naive copy method will use more
> RAM, but not 50 times more than the hard linking way.
>
> Thank you to any who respond. I hope I'm not completely out to lunch on
> this.
You could potentially save a lot of memory. *However*. You may
not want to do this, since you are defeating priviledge seperation
that is what made you want to use jails in the first place.
Specifically, using your sshd example, say I do this, and then I
end up with 50 or 100 jail instances, which I then use to do
virtual hosting for 50 or 100 different customers.
Now one customer compromises the shared copy of sshd. And can now
log into the jails of all my other customers. In other words, if
you do this, you'd better be very sure that it's read-only media,
or take other precautions.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
