From: Marc E. Fiuczynski (mef_at_CS.Princeton.EDU)
Date: Mon 13 Sep 2004 - 20:59:29 BST
Re. the perspectives you mentioned: I am definitely in the kernel integrator
camp wrt vserver, so clearly my perspective is biased. I have no idea what
you mean by "it's fine if the user has problems with the mainline version,
it's not ours..." comment.
Based on my reading of perf. numbers published in LSM's USENIX security
conference, LSM does not impact performance any more significantly than
vserver does. I.e., the numbers are so small that it doesn't really appear
to make a big difference. Correct me if I wrong! I cannot comment on LSM
being well tested or not.
More importantly, my hope is that by moving to LSM it is possible to stack
other security systems on top of vserver. I.e., I am not convinced that the
one provided by vserver is necessarily the right one beyond basic hosting
scenarios for which vserver was originally designed. There are other
scenarios where folks would benefit from vserver, but they have different
security requirements. E.g., PlanetLab uses vserver, but we also permit a
degree of sharing between vservers (both files and other kernel objects),
which you wouldn't do in basic hosting situations. Another example might be
to use vserver for "configuration isolation" on next generation consumer
electronics devices (i.e., cellular phones). Such devices are starting to
run Linux and manufactures want to run 3rd party apps on them without
compromising "safety" of the systems main operation. Any way, I am not
making this up as I have spoken to someone in this area about vserver+ckrm
and they are interested --- annecdotal evidence that vserver might be used
in environments other than basic hosting environments.
I am not a LSM expert either. Bottom line is that we do not need to stick
with the LSM API as is. Rather, where there is overlap, I am suggesting to
use the LSM API. Where there is no overlap, it would be good to see whether
the LSM interface needs to be extended, which I think is also a great
Thank you for the list. While CKRM currently does not support it, I think
that disk limits and context quota could become a CKRM controllers.
We also developed a network virtualization layer for PlanetLab, which we
incidentally call vnet. The guy who did this work, Mark Huang, noticed that
you also have a vnet and that there is overlap. Nonetheless, our work is not
intimately tied into vserver. It can be (and probably should) remain as a
separate entity. Has Mark contacted you about this yet?
I'll get back to your detailed list at some other point in time.
Vserver mailing list