On Mon, Sep 13, 2004 at 03:59:29PM -0400, Marc E. Fiuczynski wrote: > Hi Herbert,
Hi Marc! > 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. I was just assuming extreme positions on that, to depict the different viewpoints of course this isn't the case in reality ;) > 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. well, I have no numbers for example regarding LSM hooks invoked on every file access for example, or packet sent/received from the net, and I'd assume that at least when it comes to memory access, the LSM hooks probably will cause measurable overhead hopefully CKRM will do _much_ better in this area, although I haven't seen any numbers there either ... (not saying that linux-vserver is perfect there) > 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 agreed several times, that LSM is the future, and I have no problem to walk this path, will it be better? I don't know. will it be sufficient? we'll see ... > 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 > contribution!! of course ... > 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. would be happy to see _working_ memory, cpu and I/O scheduler limits and accounting first, but maybe they are somewhere? > 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? nope, not yet ... > I'll get back to your detailed list at some other point in time. great! thanks, Herbert > cheers, > Marc > > _______________________________________________ > Vserver mailing list > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
