Re: [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace

David Ahern writes: > On 7/25/18 11:38 AM, Eric W. Biederman wrote: >> >> Absolutely NOT. Global thresholds are exactly correct given the fact >> you are running on a single kernel. >> >> Memory is not free (Even though we are swimming in enough of i

Re: [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace

David Ahern writes: > On 7/25/18 6:33 AM, Eric W. Biederman wrote: >> Cong Wang writes: >> >>> On Tue, Jul 24, 2018 at 8:14 AM David Ahern wrote: >>>> >>>> On 7/19/18 11:12 AM, Cong Wang wrote: >>>>> On Thu, Jul 19, 2018 at 9:16 A

Re: [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace

Cong Wang writes: > On Tue, Jul 24, 2018 at 8:14 AM David Ahern wrote: >> >> On 7/19/18 11:12 AM, Cong Wang wrote: >> > On Thu, Jul 19, 2018 at 9:16 AM David Ahern wrote: >> >> >> >> Chatting with Nikolay about this and he brought up a good corollary - ip >> >> fragmentation. It really is a

Re: [RFC PATCH ghak32 V2 13/13] debug audit: read container ID of a process

> the full patch set and not something merely used to debug the patches. Only with an audit specific name. As it is: Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> The truth is the containerid name really stinks and is quite confusing and does not imply that the label applies only to

Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup

Christoph Hellwig <h...@lst.de> writes: > On Thu, May 17, 2018 at 12:28:01AM -0500, Eric W. Biederman wrote: >> > struct pid_namespace *proc_pid_namespace(struct inode *inode) >> > { >> >// maybe warn on for s_magic not on procfs?? &

Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup

Christoph Hellwig <h...@lst.de> writes: > On Sat, May 05, 2018 at 07:37:33AM -0500, Eric W. Biederman wrote: >> Christoph Hellwig <h...@lst.de> writes: >> >> > The shole seq_file sequence already operates under a single RCU lock pair, >> > so mo

Re: [PATCH 34/40] atm: simplify procfs code

Christoph Hellwig <h...@lst.de> writes: > On Sat, May 05, 2018 at 07:51:18AM -0500, Eric W. Biederman wrote: >> Christoph Hellwig <h...@lst.de> writes: >> >> > Use remove_proc_subtree to remove the whole subtree on cleanup, and >> > unwind the reg

Re: [PATCH net-next v8 0/3] kernel: add support to collect hardware logs in crash recovery kernel

s introduced by the last round of changes. >From 10,000 feet flyover design perspectie and from an ABI perspective this patchset seems fine. Acked-by: "Eric W. Biederman" <ebied...@xmission.com> Eric

Re: [PATCH 38/40] ide: remove ide_driver_proc_write

permissions S_IFREG|S_IRUGO so I don't think the write support was ever finished. That cap_capable in the write method looks down right scary/buggy. Acked-by: "Eric W. Biederman" <ebied...@xmission.com> Eric > > Signed-off-by: Christoph Hellwig <h...@lst.de&

Re: [PATCH 34/40] atm: simplify procfs code

Christoph Hellwig writes: > Use remove_proc_subtree to remove the whole subtree on cleanup, and > unwind the registration loop into individual calls. Switch to use > proc_create_seq where applicable. Can you please explain why you are removing the error handling when you are

Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup

Christoph Hellwig writes: > The shole seq_file sequence already operates under a single RCU lock pair, > so move the pid namespace lookup into it, and stop grabbing a reference > and remove all kinds of boilerplate code. This is wrong. Move task_active_pid_ns(current) from open to

Re: [PATCH net-next v7 1/3] vmcore: add API to collect hardware dump in second kernel

lems. Acked-by: "Eric W. Biederman" <ebied...@xmission.com> > 1. During probe (before hardware is initialized), device drivers > register to the vmcore module (via vmcore_add_device_dump()), with > callback function, along with buffer size and log name needed for > firmwar

Re: [PATCH net-next v6 0/3] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy writes: > v6: > - Reworked device dump elf note name to contain vendor identifier. > - Added vmcoredd_header that precedes actual dump in the Elf Note. > - Device dump's name is moved inside vmcoredd_header. > - Added "CHELSIO" string as vendor

Re: [PATCH net-next 0/2 v5] netns: uevent filtering

devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net) > > Thanks! > Christian > > [1]: https://lkml.org/lkml/2018/4/4/739 > [2]: https://lkml.org/lkml/2018/4/26/767 > [3]: https://lkml.org/lkml/2018/4/26/738 Acked-by: "Eric W. Bieder

Re: [PATCH net-next 0/2 v4] netns: uevent filtering

devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net) > > Thanks! > Christian > > [1]: https://lkml.org/lkml/2018/4/4/739 > [2]: https://lkml.org/lkml/2018/4/26/767 > [3]: https://lkml.org/lkml/2018/4/26/738 Again ovearall ack. One last nit that might be worth addressing. Acked-by: "Eric W. Biederman" <ebied...@xmission.com> Eric

Re: [PATCH net-next 2/2 v4] netns: restrict uevents

> + /* fix credentials */ > + if (owning_user_ns != _user_ns) { > + struct netlink_skb_parms *parms = _CB(skb); > + kuid_t root_uid; > + kgid_t root_gid; > + > + /* fix uid */ > + root_uid = make_kuid(owning_user_ns, 0); > +

Re: [PATCH net-next 1/2 v3] uevent: add alloc_uevent_skb() helper

Christian Brauner writes: > This patch adds alloc_uevent_skb() in preparation for follow up patches. > > Signed-off-by: Christian Brauner > --- > lib/kobject_uevent.c | 39 ++- > 1 file changed, 26

Re: [PATCH net-next 2/2 v3] netns: restrict uevents

Christian Brauner writes: > --- > lib/kobject_uevent.c | 140 ++- > 1 file changed, 99 insertions(+), 41 deletions(-) > > diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c > index c3cb110f663b..d8ce5e6d83af 100644 > ---

Re: [PATCH net-next 0/2] netns: uevent filtering

p1s0f1 (net) > KERNEL[625.301109] move > /devices/pci:00/:00:02.0/:01:00.1/net/enp1s0f1 (net) > KERNEL[625.301138] move > /devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net) > KERNEL[655.333272] remove > /devices/pci:00/:00:02.0/:01:00.1/ne

Re: [PATCH net-next v5 1/3] vmcore: add API to collect hardware dump in second kernel

While looking this over I found a bug in the way elf notes are being composed. Rahul Lakkireddy writes: > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c > index a45f0af22a60..7395462d2f86 100644 > --- a/fs/proc/vmcore.c > +++ b/fs/proc/vmcore.c > @@ -1145,6

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

Christian Brauner <christian.brau...@canonical.com> writes: > On Thu, Apr 26, 2018 at 12:10:30PM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> >> > On Thu, Apr 26, 2018 at 11:47:19AM -0500, Eric W. Bied

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

Christian Brauner <christian.brau...@canonical.com> writes: > On Thu, Apr 26, 2018 at 11:47:19AM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> >> > On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Bied

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

Christian Brauner <christian.brau...@canonical.com> writes: > On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> >> > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

Christian Brauner <christian.brau...@canonical.com> writes: > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman <ebied...@xmission.com> wrote: > > Bah. This code is obviously correct and probably wrong. > > How do we deliver uevents for network devices that are out

Re: [PATCH net-next 2/2 v2] netns: isolate seqnums to use per-netns locks

Christian Brauner <christian.brau...@canonical.com> writes: > On Tue, Apr 24, 2018 at 04:52:20PM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@ubuntu.com> writes: >> >> > Now that it's possible to have a different set of uevents in di

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

Bah. This code is obviously correct and probably wrong. How do we deliver uevents for network devices that are outside of the initial user namespace? The kernel still needs to deliver those. The logic to figure out which network namespace a device needs to be delivered to is is present in

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

ask per se. This > means if the user namespace of a given task is unshared but the network > namespace is kept and is owned by the initial user namespace a listener > that is opening the uevent socket in that network namespace can still > listen to uevents. > > [1]: https

Re: [PATCH net-next 2/2 v2] netns: isolate seqnums to use per-netns locks

Christian Brauner writes: > Now that it's possible to have a different set of uevents in different > network namespaces, per-network namespace uevent sequence numbers are > introduced. This increases performance as locking is now restricted to the > network

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy <rahul.lakkire...@chelsio.com> writes: > On Thursday, April 04/19/18, 2018 at 20:23:37 +0530, Eric W. Biederman wrote: >> Rahul Lakkireddy <rahul.lakkire...@chelsio.com> writes: >> >> > On Thursday, April 04/19/18, 2018 at 07:10:30 +0530,

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy writes: > On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote: >> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote: >> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote: >> > > Hi Rahul, >> > > On 04/17/18 at

Re: [PATCH net-next 2/2] netns: isolate seqnums to use per-netns locks

Christian Brauner writes: > Now that it's possible to have a different set of uevents in different > network namespaces, per-network namespace uevent sequence numbers are > introduced. This increases performance as locking is now restricted to the > network

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy writes: > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote: >> Hi Rahul, >> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote: >> > On production servers running variety of workloads over time, kernel >> > panic can happen

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner <christian.brau...@canonical.com> writes: > On Wed, Apr 11, 2018 at 11:40:14AM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> > Yeah, agreed. >> > But I think the patch is not complete. To

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner <christian.brau...@canonical.com> writes: > On Wed, Apr 11, 2018 at 01:37:18PM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> >> > On Wed, Apr 11, 2018 at 11:40:14AM -0500, Eric W. Bied

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner <christian.brau...@canonical.com> writes: > On Tue, Apr 10, 2018 at 10:04:46AM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> >> > On Mon, Apr 09, 2018 at 06:21:31PM -0500, Eric W. Bied

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner <christian.brau...@canonical.com> writes: > On Mon, Apr 09, 2018 at 06:21:31PM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> >> > On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Bied

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner <christian.brau...@canonical.com> writes: > On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> >> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tk

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner writes: >> At a practical level there should be no receivers. Plus performance >> issues. At least my memory is that any unprivileged user on the system >> is allowed to listen to those events. > > Any unprivileged user is allowed to listen to

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner <christian.brau...@canonical.com> writes: > On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote: >> Christian Brauner <christian.brau...@canonical.com> writes: >> >> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tk

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner writes: > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote: >> On 05.04.2018 17:07, Christian Brauner wrote: >> > On Thu, Apr 05, 2018 at 04:01:03PM +0300, Kirill Tkhai wrote: >> >> On 04.04.2018 22:48, Christian Brauner wrote: >>

Re: [PATCH net] netns: filter uevents correctly

Christian Brauner writes: > On Wed, Apr 04, 2018 at 09:48:57PM +0200, Christian Brauner wrote: >> commit 07e98962fa77 ("kobject: Send hotplug events in all network >> namespaces") >> >> enabled sending hotplug events into all network namespaces back in 2010. >>

Re: WARNING: refcount bug in should_fail

Al Viro writes: > On Mon, Apr 02, 2018 at 10:59:34PM +0100, Al Viro wrote: > >> FWIW, I'm going through the ->kill_sb() instances, fixing that sort >> of bugs (most of them preexisting, but I should've checked instead >> of assuming that everything's fine). Will push

Re: WARNING: refcount bug in should_fail

Tetsuo Handa writes: > syzbot wrote: >> > On Sun, Mar 4, 2018 at 6:57 AM, Tetsuo Handa >> > wrote: >> >> Switching from mm to fsdevel, for this report says that put_net(net) in >> >> rpc_kill_sb() made net->count < 0 when

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

Rahul Lakkireddy writes: > On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote: >> Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote: >> >Add a new module crashdd that exports the /sys/kernel/crashdd/ >> >directory in second

Re: [PATCH net-next v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy <rahul.lakkire...@chelsio.com> writes: > On Tuesday, March 03/27/18, 2018 at 18:47:34 +0530, Eric W. Biederman wrote: >> Rahul Lakkireddy <rahul.lakkire...@chelsio.com> writes: >> >> > On Saturday, March 03/24/18, 2018 at 20:50:52

Re: [PATCH net-next v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy <rahul.lakkire...@chelsio.com> writes: > On Saturday, March 03/24/18, 2018 at 20:50:52 +0530, Eric W. Biederman wrote: >> >> Rahul Lakkireddy <rahul.lakkire...@chelsio.com> writes: >> >> > On production servers running variety of

Re: [PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

Thadeu Lima de Souza Cascardo writes: > On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote: >> Register callback to collect hardware/firmware dumps in second kernel >> before hardware/firmware is initialized. The dumps for each device >> will be available

Re: [PATCH net-next v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy writes: > On production servers running variety of workloads over time, kernel > panic can happen sporadically after days or even months. It is > important to collect as much debug logs as possible to root cause > and fix the problem, that may not

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

Ben Greear writes: > On 03/20/2018 09:44 AM, Liran Alon wrote: >> >> >> On 20/03/18 18:24, ebied...@xmission.com wrote: >>> >>> I don't believe the current behavior is a bug. >>> >>> I looked through the history. Basically skb_scrub_packet >>> started out as the

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

Liran Alon writes: > - shmulik.ladk...@gmail.com wrote: > >> On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon >> wrote: >> > - shmulik.ladk...@gmail.com wrote: >> > >> > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon >> > >

Re: [RFC 0/2] kernel: add support to collect hardware logs in panic

Rahul Lakkireddy writes: > On production servers running variety of workloads over time, kernel > panic can happen sporadically after days or even months. It is > important to collect as much debug logs as possible to root cause > and fix the problem, that may not

Re: [PATCH net 1/1 v3] rtnetlink: require unique netns identifier

Christian Brauner writes: > On Wed, Feb 07, 2018 at 12:19:25PM +0100, Jiri Benc wrote: >> On Tue, 6 Feb 2018 14:19:02 +0100, Christian Brauner wrote: >> > +/* Verify that rtnetlink requests supporting network namespace ids >> > + * do not pass additional

Re: [PATCH net 1/1 v2] rtnetlink: require unique netns identifier

Christian Brauner writes: > On Tue, Feb 06, 2018 at 12:47:46AM +0300, Kirill Tkhai wrote: >> On 05.02.2018 18:55, Christian Brauner wrote: >> > Since we've added support for IFLA_IF_NETNSID for RTM_{DEL,GET,SET,NEW}LINK >> > it is possible for userspace to send

Re: RFC(V3): Audit Kernel Container IDs

Please let's have a description of the problem you are trying to solve. A proposed solution without talking about the problem space is useless. Any proposed solution could potentially work. I know to these exist. There is motivation for your work. What is the motivation? What problem are you

Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

Dan Williams <dan.j.willi...@intel.com> writes: > On Tue, Jan 9, 2018 at 8:17 AM, Eric W. Biederman <ebied...@xmission.com> > wrote: >> Dan Williams <dan.j.willi...@intel.com> writes: > [..] >> The user controlled value condition of your patchset imp

Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

Dan Williams <dan.j.willi...@intel.com> writes: > On Mon, Jan 8, 2018 at 7:11 PM, Eric W. Biederman <ebied...@xmission.com> > wrote: >> Dan Williams <dan.j.willi...@intel.com> writes: >> >>> Static analysis reports that 'index' may be a user controlle

Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

like a pointer would seem to provide a defense against the exfiltration technique of using the value read as an index into a small array, that user space code can probe aliased cached lines of, to see which value was dereferenced. So to this patch in particular. Nacked-by: "Eric W.

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

t even considering performance. So because the description sucks, and the due diligence is not there. Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> to the series. > > These patches also will also be available via the 'nospec' git branch > here: > > gi

Re: [PATCHv4 0/2] capability controlled user-namespaces

Mahesh Bandewar writes: > From: Mahesh Bandewar > > TL;DR version > - > Creating a sandbox environment with namespaces is challenging > considering what these sandboxed processes can engage into. e.g. > CVE-2017-6074, CVE-2017-7184,

Re: [PATCH RESEND 1/3] net: Fix possible race in peernet2id_alloc()

_cmd_fill_info(), and this race can't occur. But peernet2id_alloc() > is generic interface, and better we fix it before someone really starts > use it in wrong context. Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> I have already made a clear objection to the

Re: [PATCH 1/3] net: Fix possible race in peernet2id_alloc()

Kirill Tkhai writes: > peernet2id_alloc() is racy without rtnl_lock() as atomic_read(>count) > under net->nsid_lock does not guarantee, peer is alive: > > rcu_read_lock() > peernet2id_alloc().. > spin_lock_bh(>nsid_lock) .. >

[PATCH] net: Fix double free and memory corruption in get_net_ns_by_id()

Ryabinin <aryabi...@virtuozzo.com> Reviewed-by: "Eric W. Biederman" <ebied...@xmission.com> Signed-off-by: Eric W. Biederman <ebied...@xmission.com> --- net/core/net_namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/net_namespace.c b/net

Re: [PATCH 0/9] use network namespace for iSCSI control interfaces

David Laight writes: > To make matters even more annoying the functions for holding and > releasing a namespace are GPL_ONLY :-( I am going to pick on this by itself for a moment without mentioning anything else, so as hopefully not to derail what otherwise sounds like

Re: [PATCH RFC 00/25] Replacing net_mutex with rw_semaphore

Kirill Tkhai writes: > Hi, > > this is continuation of discussion from here: > > https://lkml.org/lkml/2017/11/14/298 > > The plan has changed a little bit, so I'd be happy to hear > people's comments, before I dived into all 400+ pernet subsys > and devices. > > The patch

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

Kirill Tkhai <ktk...@virtuozzo.com> writes: > On 15.11.2017 19:29, Eric W. Biederman wrote: >> Kirill Tkhai <ktk...@virtuozzo.com> writes: >> >>> On 15.11.2017 09:25, Eric W. Biederman wrote: >>>> Kirill Tkhai <ktk...@virtuozzo.com> write

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

Kirill Tkhai <ktk...@virtuozzo.com> writes: > On 15.11.2017 19:31, Eric W. Biederman wrote: >> Kirill Tkhai <ktk...@virtuozzo.com> writes: >> >>> On 15.11.2017 12:51, Kirill Tkhai wrote: >>>> On 15.11.2017 06:19, Eric W. Biederman wrote:

[PATCH net] net/sctp: Always set scope_id in sctp_inet6_skb_msgname

r Potapenko <gli...@google.com> Signed-off-by: "Eric W. Biederman" <ebied...@xmission.com> --- net/sctp/ipv6.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c index a6dfa86c0201..3b18085e3b10 100644 --- a/net/sctp/ipv6.c +

Re: [PATCH] net: recvmsg: Unconditionally zero struct sockaddr_storage

Kees Cook <keesc...@chromium.org> writes: > On Wed, Nov 1, 2017 at 5:48 AM, Eric W. Biederman <ebied...@xmission.com> > wrote: >> Eric Dumazet <eric.duma...@gmail.com> writes: >> >>> On Tue, 2017-10-31 at 09:14 -0700, Kees Cook wrote: >>&

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

Kirill Tkhai <ktk...@virtuozzo.com> writes: > On 15.11.2017 12:51, Kirill Tkhai wrote: >> On 15.11.2017 06:19, Eric W. Biederman wrote: >>> Kirill Tkhai <ktk...@virtuozzo.com> writes: >>> >>>> On 14.11.2017 21:39, Cong Wang wrote: >&

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

Kirill Tkhai <ktk...@virtuozzo.com> writes: > On 15.11.2017 09:25, Eric W. Biederman wrote: >> Kirill Tkhai <ktk...@virtuozzo.com> writes: >> >>> Curently mutex is used to protect pernet operations list. It makes >>> cleanup_net() to execute ->ex

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

Kirill Tkhai writes: > Curently mutex is used to protect pernet operations list. It makes > cleanup_net() to execute ->exit methods of the same operations set, > which was used on the time of ->init, even after net namespace is > unlinked from net_namespace_list. > > But

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

Kirill Tkhai writes: > On 14.11.2017 21:39, Cong Wang wrote: >> On Tue, Nov 14, 2017 at 5:53 AM, Kirill Tkhai wrote: >>> @@ -406,7 +406,7 @@ struct net *copy_net_ns(unsigned long flags, >>> >>> get_user_ns(user_ns); >>> >>> - rv =

Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces

"Mahesh Bandewar (महेश बंडेवार)" writes: > [resend response as earlier one failed because of formatting issues] > > On Thu, Nov 9, 2017 at 12:21 PM, Serge E. Hallyn wrote: >> >> On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Bandewar (महेश बंडेवार) >>

Re: [PATCH] net: recvmsg: Unconditionally zero struct sockaddr_storage

Eric Dumazet writes: > On Tue, 2017-10-31 at 09:14 -0700, Kees Cook wrote: >> Some protocols do not correctly wipe the contents of the on-stack >> struct sockaddr_storage sent down into recvmsg() (e.g. SCTP), and leak >> kernel stack contents to userspace. This wipes it

Re: [PATCH 1/1] Change ping_group_range default to what Android's init script sets.

Rob Landley writes: > From: Rob Landley > > See message from the Android "native tools and libraries team" lead > (I.E. the maintainer of bionic, adb, toolbox, etc) at > http://lists.landley.net/pipermail/toybox-landley.net/2017-July/009103.html Sigh. The

Re: RFC(v2): Audit Kernel Container IDs

Paul Moore <p...@paul-moore.com> writes: > On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman > <ebied...@xmission.com> wrote: >> Aleksa Sarai <asa...@suse.de> writes: >>>>> The security implications are that anything that can change the label >

Re: RFC(v2): Audit Kernel Container IDs

Aleksa Sarai writes: >>> The security implications are that anything that can change the label >>> could also hide itself and its doings from the audit system and thus >>> would be used as a means to evade detection. I actually think this >>> means the label should be write once

Re: RFC: making cn_proc work in {pid,user} namespaces

Aleksa Sarai writes: > Hi all, > > At the moment, cn_proc is not usable by containers or container runtimes. In > addition, all connectors have an odd relationship with init_net (for example, > /proc/net/connectors only exists in init_net). There are two main use-cases > that >

Re: RFC(v2): Audit Kernel Container IDs

Richard Guy Briggs writes: > A namespace cannot directly migrate from one container to another but > could be assigned to a newly spawned container. A namespace can be > moved from one container to another indirectly by having that namespace > used in a second process in

Re: RFC: Audit Kernel Container IDs

Richard Guy Briggs <r...@redhat.com> writes: > On 2017-09-14 12:33, Eric W. Biederman wrote: >> Richard Guy Briggs <r...@redhat.com> writes: >> >> > The trigger is a pseudo filesystem (proc, since PID tree already exists) >> > write of a u64 represe

Re: RFC: Audit Kernel Container IDs

Richard Guy Briggs writes: > The trigger is a pseudo filesystem (proc, since PID tree already exists) > write of a u64 representing the container ID to a file representing a > process that will become the first process in a new container. > This might place restrictions on mount

Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN

Prakash Sangappa writes: > On 8/30/17 10:41 AM, ebied...@xmission.com wrote: >> Prakash Sangappa writes: >> >> >>> With regards to security, the question basically is what is the consequence >>> of passing the wrong id. As I understand

Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN

Prakash Sangappa writes: > On 8/29/17 5:10 PM, ebied...@xmission.com wrote: > > "prakash.sangappa" writes: > > On 08/29/2017 04:02 PM, David Miller wrote: > > From: Prakash Sangappa > Date: Mon, 28 Aug

Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN

"prakash.sangappa" writes: > On 08/29/2017 04:02 PM, David Miller wrote: >> From: Prakash Sangappa >> Date: Mon, 28 Aug 2017 17:12:20 -0700 >> >>> Currently passing tid(gettid(2)) of a thread in struct ucred in >>> SCM_CREDENTIALS

Re: [PATCH iproute2] netns: make /var/run/netns bind-mount recursive

ns.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> > > Looks good, but I want a review by Eric to make sure this doesn't > break other things. Acked-by: "Eric W. Biederman" <ebied...@xmission.com> I don't see any possible problems with th

Re: [PATCH 1/3] ipv4: initialize fib_trie prior to register_netdev_notifier call.

b 08 4c 89 ff e8 16 47 01 00 48 8b 44 24 38 <45> 8b 6e 14 4d > 63 76 74 48 89 04 24 0f 1f 44 00 00 48 83 c4 08 > RIP: kmem_cache_alloc+0xcf/0x1c0 RSP: 9b1500017c28 > CR2: 0014 > > Fixes: 7b1a74fdbb9e ("[NETNS]: Refactor fib initialization so it can

Re: [CRIU] BUG: Dentry ffff9f795a08fe60{i=af565f, n=lo} still in use (1) [unmount of proc proc]

Andrei Vagin writes: > I did a few experiments and found that the bug is reproduced for 6-12 > hours on the our test server. Then I reverted two patches and the server > is working normally for more than 24 hours already, so the bug is > probably in one of these patches. > >

Re: [PATCH 0/2] bring UP loopback device at initialziation

"Mahesh Bandewar (महेश बंडेवार)" writes: >> I wonder if it is too late to change this since this behavior is probably >> from the beginning of network namespace. A networkless netns is also >> useful at least for testing purpose, we do use it as a sandbox. >> > Sandbox is my

Re: [PATCH 1/2] ipv4: initialize fib_trie prior to register_netdev_notifier call.

Mahesh Bandewar writes: > From: Mahesh Bandewar > > Net stack initialization currently initializes fib-trie after the > first call to netdevice_notifier() call. It does not cause any problem > since there are no devices UP at this moment, but trying to

Re: RFC: bring UP 'lo' by default after creating new netns

"Mahesh Bandewar (महेश बंडेवार)" writes: > Creation of new network namespace is almost always followed up by > bringing up the loopback device. > > ip netns add foo > ip -netns foo link set lo up > > I'm not sure if there are any consequences of bringing the

Re: Receiving raw packets (incl. VLAN tags) on raw sockets

Jan Grashöfer <jan.grashoe...@gmail.com> writes: > On 14/06/17 16:41, Eric W. Biederman wrote: >> That does not work. That is is just the software fallback for when >> the device driver does not have a special case the processing >> vlan tagged packets. >> &

Re: Receiving raw packets (incl. VLAN tags) on raw sockets

Jan Grashöfer writes: > Hello, > > trying to ingest packets to a network monitoring tool using AF_Packet, I > noticed that VLAN tags are stripped off even if VLAN offloading is > disabled. As described in [1] the tags are stripped that early in the > receive path that

Re: [PATCH nf-next] netns: add and use net_ns_barrier

ep the existing behaviour around, > people has been relying on this rmmod feature to globally disable > helpers. It's very old thing indeed and as you can see, very sparse > grain for the netns era... But still I think we need this. > > So I'm inclined to take this, and keep an eye to

Re: loosing netdevices with namespaces and unshare?

Cong Wang <xiyou.wangc...@gmail.com> writes: > On Wed, May 31, 2017 at 11:32 PM, Eric W. Biederman > <ebied...@xmission.com> wrote: >> Cong Wang <xiyou.wangc...@gmail.com> writes: >>> Network namespace does not special-case the physical devices, >>

Re: loosing netdevices with namespaces and unshare?

Harald Welte <lafo...@gnumonks.org> writes: > Hi Eric, > > On Thu, Jun 01, 2017 at 01:32:49AM -0500, Eric W. Biederman wrote: > >> If a network device does not implement rntl_link_ops it is returned to >> the initial network namespace. Anything else will loose p

Re: loosing netdevices with namespaces and unshare?

Cong Wang writes: > Network namespace does not special-case the physical devices, > it treats them all equally as abstract net devices. Absolutely not true. The relevant code is in net/core/dev.c:default_device_exit If a network device does not implement rntl_link_ops

Re: [PATCH nf-next] netns: add and use net_ns_barrier

et() > > but because netns is already gone from list the for_each_net() loop > doesn't include it, therefore all of these conntracks are unaffected. > > 6. helper module unload finishes > 7. netns wq invokes destructor for rmmod'ed helper > > CC: "Eric W. Biederman"

Re: [PATCH nf-next] netns: add and use net_ns_barrier

s are unaffected. >> >> 6. helper module unload finishes >> 7. netns wq invokes destructor for rmmod'ed helper >> >> CC: "Eric W. Biederman" <ebied...@xmission.com> >> Reported-by: Joe Stringer <j...@ovn.org> >> Signed-off-by: Floria

Re: [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE

"Mahesh Bandewar (महेश बंडेवार)" <mahe...@google.com> writes: > On Mon, May 15, 2017 at 6:52 AM, David Miller <da...@davemloft.net> wrote: >> From: Greg Kroah-Hartman <gre...@linuxfoundation.org> >> Date: Mon, 15 May 2017 08:10:59 +0200 >> >

Re: [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE

Greg Kroah-Hartman writes: > On Fri, May 12, 2017 at 04:22:59PM -0700, Mahesh Bandewar wrote: >> From: Mahesh Bandewar >> >> A process inside random user-ns should not load a module, which is >> currently possible. As demonstrated in following

  1   2   3   4   5   6   7   8   9   10   >