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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).