From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 13 Sep 2004 - 22:03:31 BST
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
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver