From: Jeff Garzik <jeff@garzik.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>,
kaber@trash.net, netdev@vger.kernel.org, hadi@cyberus.ca,
shemminger@linux-foundation.org, greearb@candelatech.com,
yoshfuji@linux-ipv6.org, containers@lists.osdl.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFD] L2 Network namespace infrastructure
Date: Sat, 23 Jun 2007 21:28:44 -0400 [thread overview]
Message-ID: <467DC8CC.3020002@garzik.org> (raw)
In-Reply-To: <m1ejk28eku.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Jeff Garzik <jeff@garzik.org> writes:
>
>> David Miller wrote:
>>> I don't accept that we have to add another function argument
>>> to a bunch of core routines just to support this crap,
>>> especially since you give no way to turn it off and get
>>> that function argument slot back.
>>>
>>> To be honest I think this form of virtualization is a complete
>>> waste of time, even the openvz approach.
>>>
>>> We're protecting the kernel from itself, and that's an endless
>>> uphill battle that you will never win. Let's do this kind of
>>> stuff properly with a real minimal hypervisor, hopefully with
>>> appropriate hardware level support and good virtualized device
>>> interfaces, instead of this namespace stuff.
>> Strongly seconded. This containerized virtualization approach just bloats up
>> the kernel for something that is inherently fragile and IMO less secure --
>> protecting the kernel from itself.
>>
>> Plenty of other virt approaches don't stir the code like this, while
>> simultaneously providing fewer, more-clean entry points for the virtualization
>> to occur.
>
> Wrong. I really don't want to get into a my virtualization approach is better
> then yours. But this is flat out wrong.
> 99% of the changes I'm talking about introducing are just:
> - variable
> + ptr->variable
>
> There are more pieces mostly with when we initialize those variables but
> that is the essence of the change.
You completely dodged the main objection. Which is OK if you are
selling something to marketing departments, but not OK
Containers introduce chroot-jail-like features that give one a false
sense of security, while still requiring one to "poke holes" in the
illusion to get hardware-specific tasks accomplished.
The capable/not-capable model (i.e. superuser / normal user) is _still_
being secured locally, even after decades of work and whitepapers and
audits.
You are drinking Deep Kool-Aid if you think adding containers to the
myriad kernel subsystems does anything besides increasing fragility, and
decreasing security. You are securing in-kernel subsystems against
other in-kernel subsystems. superuser/user model made that difficult
enough... now containers add exponential audit complexity to that. Who
is to say that a local root does not also pierce the container model?
> And as opposed to other virtualization approaches so far no one has been
> able to measure the overhead. I suspect there will be a few more cache
> line misses somewhere but they haven't shown up yet.
>
> If the only use was strong isolation which Dave complains about I would
> concur that the namespace approach is inappropriate. However there are
> a lot other uses.
Sure there are uses. There are uses to putting the X server into the
kernel, too. At some point complexity and featuritis has to take a back
seat to basic sanity.
Jeff
next prev parent reply other threads:[~2007-06-24 1:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-22 19:39 [RFD] L2 Network namespace infrastructure Eric W. Biederman
2007-06-22 21:22 ` [PATCH] net: Basic network " Eric W. Biederman
2007-06-23 10:40 ` [RFD] L2 Network " Patrick McHardy
2007-06-23 15:20 ` Ben Greear
2007-06-23 17:26 ` Eric W. Biederman
2007-06-23 20:09 ` Ben Greear
2007-06-23 20:39 ` Eric W. Biederman
2007-06-23 20:44 ` Ben Greear
2007-06-23 17:26 ` Stephen Hemminger
2007-06-23 17:55 ` Eric W. Biederman
2007-06-23 20:03 ` Ben Greear
2007-06-27 14:41 ` [Devel] " Kirill Korotaev
2007-06-23 17:19 ` Eric W. Biederman
2007-06-23 18:00 ` Patrick McHardy
2007-06-23 19:08 ` Eric W. Biederman
2007-06-23 20:19 ` Carl-Daniel Hailfinger
2007-06-23 20:31 ` Eric W. Biederman
2007-06-23 20:57 ` David Miller
2007-06-23 21:22 ` Benny Amorsen
2007-06-24 5:39 ` David Miller
2007-06-23 21:41 ` Eric W. Biederman
2007-06-24 5:45 ` David Miller
2007-06-24 12:58 ` Eric W. Biederman
2007-06-25 2:39 ` David Miller
2007-06-26 15:32 ` Eric W. Biederman
2007-06-23 22:15 ` Jeff Garzik
2007-06-23 22:56 ` Eric W. Biederman
2007-06-24 1:28 ` Jeff Garzik [this message]
2007-06-25 15:23 ` Serge E. Hallyn
2007-06-27 15:38 ` [Devel] " Kirill Korotaev
2007-06-24 5:48 ` David Miller
2007-06-24 10:25 ` Benny Amorsen
2007-06-24 12:38 ` Eric W. Biederman
2007-06-25 15:11 ` Serge E. Hallyn
2007-06-28 14:53 ` Kirill Korotaev
2007-06-27 14:39 ` [Devel] " Kirill Korotaev
2007-06-27 14:45 ` Patrick McHardy
2007-06-27 14:56 ` Ben Greear
2007-06-28 13:12 ` Kirill Korotaev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=467DC8CC.3020002@garzik.org \
--to=jeff@garzik.org \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.osdl.org \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=greearb@candelatech.com \
--cc=hadi@cyberus.ca \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
--cc=torvalds@linux-foundation.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.