All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: "Yuriy M. Kaminskiy" <yumkam@gmail.com>
Cc: netdev@vger.kernel.org, containers@lists.osdl.org,
	linux-kernel@vger.kernel.org
Subject: Re: userns, netns, and quick physical memory consumption by unprivileged user
Date: Fri, 11 Mar 2016 16:34:06 +0100	[thread overview]
Message-ID: <20160311153406.GB6620@breakpoint.cc> (raw)
In-Reply-To: <m3r3fhhx4c.fsf@gmail.com>

Yuriy M. Kaminskiy <yumkam@gmail.com> wrote:
> BTW, all those hash/conntrack/etc default sizes was calculated from
> physical memory size in assumption there will be only *one* instance of
> those tables. Obviously, introduction of network namespaces (and
> especially unprivileged user-ns) thrown this assumption in the window
> (and here comes that "falling back to vmalloc" message again; in pre-netns
> world, those tables were allocated *once* on early system startup, with
> typically plenty of free and unfragmented memory).

No idea how to fix this expect by removing conntrack support in net
namespaces completely.

I'd disallow all write accesses to skb->nfct (NAT, CONNMARK,
CONNSECMARK, ...) and then no longer clear skb->nfct when forwarding
packet from init_ns to container.

Containers could then still test conntrack as seen from init namespace pov
in PREROUTING/FORWARD/INPUT (but not OUTPUT, obviously).

[ OUTPUT *might* be doable as well by allowing NEW creation in output
  but skipping nat and deferring the confirmation/commit of the new
  entry to the table until skb leaves initns ]

We could key conntrack entries to initns conntrack table
instead of adding one new table per netns, but seems like this only
replaces one problem with a new one (filling/blocking initns table from
another netns).

Maybe we could go with a compromise and skip/disallow conntrack in
unpriv userns only?

  reply	other threads:[~2016-03-11 15:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 20:38 [q] userns, netns, and quick physical memory consumption by unprivileged user Yuriy M. Kaminskiy
2016-03-11 15:06 ` Yuriy M. Kaminskiy
2016-03-11 15:06   ` Yuriy M. Kaminskiy
2016-03-11 15:34   ` Florian Westphal [this message]
2016-03-12 11:41     ` Pablo Neira Ayuso
2016-03-12 13:35     ` Yuriy M. Kaminskiy
2016-03-14  9:14   ` Michal Hocko
2016-03-14 15:12     ` Yuriy M. Kaminskiy

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=20160311153406.GB6620@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=containers@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yumkam@gmail.com \
    /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.