Re: [PATCH] Add finit_module syscall for Linux

On Wednesday 23 January 2013 11:43:45 Joseph S. Myers wrote:
> On Tue, 22 Jan 2013, Kees Cook wrote:
> > Yeah, seems true. Weird. The callers (e.g. kmod) use their own externs.
> > Hmpf
> > 
> > $ readelf -s /lib/x86_64-linux-gnu/libc.so.6  | grep init_module
> >    894: 00000000000f77d0    36 FUNC    GLOBAL DEFAULT   12
> > init_module@@GLIBC_2.2.5
> > 
> > But it is exported. Is this something to fix, or should finit_module
> > follow this lead?
> 
> The kexec_load discussion suggested that the init_module export should be
> considered a historical bad decision; because it was exported from shared
> libc long ago, it can't now be removed, but that doesn't mean its example
> should be followed for any new related syscalls, if the "syscall" function
> is sufficient to use them from user code and they are extremely
> specialized.

we can stop exporting it so new apps stop linking against it (but continue to 
provide the versioned symbol for old apps).  if we think including the module 
funcs is a historical mistake, then let's make that more explicit by breaking 
code that tries to link against it.

that said, i think it is useful to have a centralized location for syscall 
wrappers.  everyone having to implement their own init_module() { syscall() } 
wrapper means packages can easily introduce their own subtle bug (in terms of 
the # of parameters the func takes).

what if we just included all these syscall wrappers in libc_nonshared.a ?  
that way we minimize the baggage ...
-mike