linux-kernel - Re: [RFC PATCH 4/4] kernel: add support for 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130823165528.GC2336@localhost.localdomain>
Date:	Fri, 23 Aug 2013 18:55:28 +0200
From:	Frantisek Hrbata <fhrbata@...hat.com>
To:	Peter Oberparleiter <oberpar@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, jstancek@...hat.com,
	keescook@...omium.org, rusty@...tcorp.com.au,
	linux-arch@...r.kernel.org, arnd@...db.de, mgahagan@...hat.com,
	agospoda@...hat.com
Subject: Re: [RFC PATCH 4/4] kernel: add support for init_array constructors

On Fri, Aug 23, 2013 at 05:13:31PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > This adds the .init_array section as yet another section with constructors. This
> > is needed because gcc is adding __gcov_init calls to .init_array.
> > 
> > Signed-off-by: Frantisek Hrbata <fhrbata@...hat.com>
> > ---
> >  include/asm-generic/vmlinux.lds.h | 1 +
> >  include/linux/module.h            | 2 ++
> >  kernel/module.c                   | 6 ++++++
> >  3 files changed, 9 insertions(+)
> > 
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index 69732d2..c55d8d9 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -468,6 +468,7 @@
> >  #define KERNEL_CTORS()	. = ALIGN(8);			   \
> >  			VMLINUX_SYMBOL(__ctors_start) = .; \
> >  			*(.ctors)			   \
> > +			*(.init_array)			   \
> 
> This is exactly how I (would) have done it.
> 
> >  			VMLINUX_SYMBOL(__ctors_end) = .;
> >  #else
> >  #define KERNEL_CTORS()
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 46f1ea0..89ff829 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -374,6 +374,8 @@ struct module
> >  	/* Constructor functions. */
> >  	ctor_fn_t *ctors;
> >  	unsigned int num_ctors;
> > +	ctor_fn_t *init_array;
> > +	unsigned int num_init_array;
> 
> I think it would be safe to re-use the ctors-related fields here. Each GCC
> version will only ever create either of .ctors or .init_array, but never
> both. 
> The only case where separate fields would be required, would be when
> linking a kernel module from multiple object files compiled with different
> versions of GCC.

Ah ok, I was not aware of this.

> 
> >  #endif
> >  };
> >  #ifndef MODULE_ARCH_INIT
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 2069158..581ae89 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -2760,6 +2760,9 @@ static void find_module_sections(struct module *mod, struct load_info *info)
> >  #ifdef CONFIG_CONSTRUCTORS
> >  	mod->ctors = section_objs(info, ".ctors",
> >  				  sizeof(*mod->ctors), &mod->num_ctors);
> 
> When reusing mod->ctors, you could check for mod->ctors == NULL here and
> fill in the values from section_objs(".init_array").

Yes, in the case that we only have .ctors or .init_array section, this sounds
as the right approach.

> 
> > +	mod->init_array = section_objs(info, ".init_array",
> > +				  sizeof(*mod->init_array),
> > +				  &mod->num_init_array);
> >  #endif
> > 
> >  #ifdef CONFIG_TRACEPOINTS
> > @@ -3024,6 +3027,9 @@ static void do_mod_ctors(struct module *mod)
> > 
> >  	for (i = 0; i < mod->num_ctors; i++)
> >  		mod->ctors[i]();
> > +
> > +	for (i = 0; i < mod->num_init_array; i++)
> > +		mod->init_array[i]();
> >  #endif
> >  }
> > 
> 
> -- 
> Peter Oberparleiter
> Linux on System z Development - IBM Germany
> 

-- 
Frantisek Hrbata
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/