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]
Date:	Mon, 19 Mar 2012 19:17:47 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Jan Beulich" <JBeulich@...e.com>
Cc:	"Sam Ravnborg" <sam@...nborg.org>,
	"David Miller" <davem@...emloft.net>, <xemul@...nvz.org>,
	<netdev@...r.kernel.org>, <netfilter-devel@...r.kernel.org>
Subject: Re: [PATCH] adjust __net_exit

"Jan Beulich" <JBeulich@...e.com> writes:

>>>> On 19.03.12 at 09:47, Sam Ravnborg <sam@...nborg.org> wrote:
>>> >> > Using the (bogus and unused elsewhere)
>>> >> > __exit_refok to implement this is inefficient - any non-modular code
>>> >> > really can reside in __init (as non-modular __exit code is never used).
>> 
>>> > 2) fix up the bogus commit message
>>> 
>>> Bogus in what way?
>> 
>> I fail to see that __exit_refok is bogus.
>
> Either an exit function references only permitted code (in which case
> it is legitimately using __exit), or it references non-__exit code, in
> which case it shouldn't have an override at all. Permitting an exit
> function to reference e.g. __init code is suspicious (at best) in all
> cases I can think of (in contrast to allowing a non-init function to
> reference __init code on a code path that can be proven to be taken
> only during system startup).

My apologies I said that there was nothing network namespace specific
left to talk about and I had goofed in my analysis.  The weirdness with
references comes from how struct pernet_operations is used.

Structures of type struct pernet_operations hold holds pointers to .init
functions marked as __net_init and .exit and .exit_batch marked as
__net_exit.

The assertion is that references from static instances of struct
pernet_operations that live in __net_initdata should be ok.


Structures of type pernet_operations are passed to
register_pernet_subsys or register_pernet_device which ultimately call
register_pernet_operations.  Register pernet_operations when the network
namespace is disabled simply calls the .init function when the network
namespace code is compiled out.  The .exit and .exit_batch functions
are not referenced at all.

When the network namespace code is compiled in __net_init __net_exit
and __net_initdata all go away.

So the exit function references only permitted code.  But the exit
function is being referenced by data in an init section which requires
the override.

How should we mark functions in __net_exit that can be thrown away
when outside of a module and never even loaded when compiled into the
kernel when the network namespace is disabled?

The original definition of __exit_refok seemed to say this very clearly
to me.  This is an __exit section but references to it from __init data
are ok.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ