netdev - Re: [Patch net-next v2 2/2] netpoll: use the net namespace of current process instead of init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <878v7clu3t.fsf@xmission.com>
Date:	Mon, 28 Jan 2013 16:18:30 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David Miller <davem@...emloft.net>
Cc:	amwang@...hat.com, netdev@...r.kernel.org
Subject: Re: [Patch net-next v2 2/2] netpoll: use the net namespace of current process instead of init_net

David Miller <davem@...emloft.net> writes:

> From: Cong Wang <amwang@...hat.com>
> Date: Mon, 28 Jan 2013 09:55:21 +0800
>
>> From: Cong Wang <amwang@...hat.com>
>> 
>> This will allow us to setup netconsole in a different namespace
>> rather than where init_net is.
>> 
>> Cc: Eric W. Biederman <ebiederm@...ssion.com>
>> Cc: David S. Miller <davem@...emloft.net>
>> Signed-off-by: Cong Wang <amwang@...hat.com>
>
> Applied but:
>
>> +	if (np->dev_name) {
>> +		struct net *net = current->nsproxy->net_ns;
>> +		ndev = __dev_get_by_name(net, np->dev_name);
>> +	}
>
> I wonder if you should be using task_nsproxy() here.

At a practical level using nsproxy straight is what we want here,
as nsproxy can not be changed by anything other than the current
process.  So we have an implicit lock just by being the current
process.

Now there might be some set of rules for error checking that
I am not up to speed on that says because some paths that do
the rcu dance:

	rcu_read_lock();
	nsproxy =  rcu_dereference(tsk->nsproxy);
        net = get_net(nsproxy->net_ns);
        rcu_read_lock();

That all paths have to do a companion rcu dance to say this is a
place where we don't need rcu protection because this is the
current process and we don't need an rcu_lock here.

If there is such a set of rules we have at least 24 other places
in the kernel that need to be fixed.

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html