netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



  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).