[PATCH] Add finit_module syscall for Linux

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PATCH] Add finit_module syscall for Linux

Kees Cook-2
This adds the new Linux finit_module() syscall.

Signed-off-by: Kees Cook <[hidden email]>

---
 sysdeps/unix/sysv/linux/syscalls.list |    1 +
 1 file changed, 1 insertion(+)

2013-01-22  Kees Cook  <[hidden email]>

        * sysdeps/unix/sysv/linux/syscalls.list: Add finit_module.

diff --git a/sysdeps/unix/sysv/linux/syscalls.list b/sysdeps/unix/sysv/linux/syscalls.list
index 2e6cf9c..55748c9 100644
--- a/sysdeps/unix/sysv/linux/syscalls.list
+++ b/sysdeps/unix/sysv/linux/syscalls.list
@@ -28,6 +28,7 @@ getresgid - getresgid i:ppp getresgid
 getrlimit - ugetrlimit i:ip __new_getrlimit __getrlimit getrlimit@@GLIBC_2.2
 getsid - getsid i:i getsid
 init_module EXTRA init_module 5 init_module
+finit_module EXTRA finit_module i:isi finit_module
 inotify_add_watch EXTRA inotify_add_watch i:isi inotify_add_watch
 inotify_init EXTRA inotify_init i: inotify_init
 inotify_init1 EXTRA inotify_init1 i:I inotify_init1
--
1.7.9.5

--
Kees Cook
Chrome OS Security
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Joseph Myers
On Tue, 22 Jan 2013, Kees Cook wrote:

> This adds the new Linux finit_module() syscall.

There's no point in adding syscalls to syscalls.list without at least
adding a symbol version so the function is actually exported from libc.so.  
Note that in the kexec_load discussion last May / June, doubts were
expressed about whether some existing module-related syscalls really
should have had functions in glibc.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Mike Frysinger
On Tuesday 22 January 2013 22:16:38 Joseph S. Myers wrote:
> On Tue, 22 Jan 2013, Kees Cook wrote:
> > This adds the new Linux finit_module() syscall.
>
> There's no point in adding syscalls to syscalls.list without at least
> adding a symbol version so the function is actually exported from libc.so.
> Note that in the kexec_load discussion last May / June, doubts were
> expressed about whether some existing module-related syscalls really
> should have had functions in glibc.

the lack of a header file that exports prototypes for these functions seems
like bad form too (not a new issue to finit_module)
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Kees Cook-2
In reply to this post by Joseph Myers
On Tue, Jan 22, 2013 at 7:16 PM, Joseph S. Myers
<[hidden email]> wrote:
> On Tue, 22 Jan 2013, Kees Cook wrote:
>
>> This adds the new Linux finit_module() syscall.
>
> There's no point in adding syscalls to syscalls.list without at least
> adding a symbol version so the function is actually exported from libc.so.
> Note that in the kexec_load discussion last May / June, doubts were
> expressed about whether some existing module-related syscalls really
> should have had functions in glibc.

Hm, okay. I tried to find some good examples, but the git history on
syscalls.list made it difficult. There doesn't seem to be anything
special done for init_module(), so I guess I'm confused what's needed
here for finit_module(). I'll go see if the kexec_load discussion will
shed the light I need. :)

Thanks!

-Kees

--
Kees Cook
Chrome OS Security
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Kees Cook-2
In reply to this post by Mike Frysinger
On Tue, Jan 22, 2013 at 7:34 PM, Mike Frysinger <[hidden email]> wrote:

> On Tuesday 22 January 2013 22:16:38 Joseph S. Myers wrote:
>> On Tue, 22 Jan 2013, Kees Cook wrote:
>> > This adds the new Linux finit_module() syscall.
>>
>> There's no point in adding syscalls to syscalls.list without at least
>> adding a symbol version so the function is actually exported from libc.so.
>> Note that in the kexec_load discussion last May / June, doubts were
>> expressed about whether some existing module-related syscalls really
>> should have had functions in glibc.
>
> the lack of a header file that exports prototypes for these functions seems
> like bad form too (not a new issue to finit_module)

I got the impression those were auto-generated from syscalls.list
(which contains the prototype in an encoded for ("i:isi" in
finit_module's case). And that this generation is what converts the
syscall into return value and errno?

-Kees

--
Kees Cook
Chrome OS Security
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Mike Frysinger
On Tuesday 22 January 2013 23:06:06 Kees Cook wrote:

> On Tue, Jan 22, 2013 at 7:34 PM, Mike Frysinger <[hidden email]> wrote:
> > On Tuesday 22 January 2013 22:16:38 Joseph S. Myers wrote:
> >> On Tue, 22 Jan 2013, Kees Cook wrote:
> >> > This adds the new Linux finit_module() syscall.
> >>
> >> There's no point in adding syscalls to syscalls.list without at least
> >> adding a symbol version so the function is actually exported from
> >> libc.so. Note that in the kexec_load discussion last May / June, doubts
> >> were expressed about whether some existing module-related syscalls
> >> really should have had functions in glibc.
> >
> > the lack of a header file that exports prototypes for these functions
> > seems like bad form too (not a new issue to finit_module)
>
> I got the impression those were auto-generated from syscalls.list
> (which contains the prototype in an encoded for ("i:isi" in
> finit_module's case). And that this generation is what converts the
> syscall into return value and errno?
syscalls.list auto generates the simple funcs in glibc that are glorified
syscall() calls, but they don't (afaik) generate headers.  grepping installed
glibc headers doesn't show any match that i can see either.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Kees Cook-2
On Tue, Jan 22, 2013 at 9:02 PM, Mike Frysinger <[hidden email]> wrote:

> On Tuesday 22 January 2013 23:06:06 Kees Cook wrote:
>> On Tue, Jan 22, 2013 at 7:34 PM, Mike Frysinger <[hidden email]> wrote:
>> > On Tuesday 22 January 2013 22:16:38 Joseph S. Myers wrote:
>> >> On Tue, 22 Jan 2013, Kees Cook wrote:
>> >> > This adds the new Linux finit_module() syscall.
>> >>
>> >> There's no point in adding syscalls to syscalls.list without at least
>> >> adding a symbol version so the function is actually exported from
>> >> libc.so. Note that in the kexec_load discussion last May / June, doubts
>> >> were expressed about whether some existing module-related syscalls
>> >> really should have had functions in glibc.
>> >
>> > the lack of a header file that exports prototypes for these functions
>> > seems like bad form too (not a new issue to finit_module)
>>
>> I got the impression those were auto-generated from syscalls.list
>> (which contains the prototype in an encoded for ("i:isi" in
>> finit_module's case). And that this generation is what converts the
>> syscall into return value and errno?
>
> syscalls.list auto generates the simple funcs in glibc that are glorified
> syscall() calls, but they don't (afaik) generate headers.  grepping installed
> glibc headers doesn't show any match that i can see either.
> -mike

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?

-Kees

--
Kees Cook
Chrome OS Security
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Kees Cook-2
In reply to this post by Kees Cook-2
On Tue, Jan 22, 2013 at 8:04 PM, Kees Cook <[hidden email]> wrote:

> On Tue, Jan 22, 2013 at 7:16 PM, Joseph S. Myers
> <[hidden email]> wrote:
>> On Tue, 22 Jan 2013, Kees Cook wrote:
>>
>>> This adds the new Linux finit_module() syscall.
>>
>> There's no point in adding syscalls to syscalls.list without at least
>> adding a symbol version so the function is actually exported from libc.so.
>> Note that in the kexec_load discussion last May / June, doubts were
>> expressed about whether some existing module-related syscalls really
>> should have had functions in glibc.
>
> Hm, okay. I tried to find some good examples, but the git history on
> syscalls.list made it difficult. There doesn't seem to be anything
> special done for init_module(), so I guess I'm confused what's needed
> here for finit_module(). I'll go see if the kexec_load discussion will
> shed the light I need. :)

Ah-ha. I think I see what I missed. It looks like I need to add it to
the arch-specific .ablist files as well as the Versions file? I was
hoping to avoid the arch-specific stuff, since it should be available
on any arch that hooks it up.

-Kees

--
Kees Cook
Chrome OS Security
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Florian Weimer-5
In reply to this post by Kees Cook-2
On 01/23/2013 06:26 AM, 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?

I think RPM-based distributions will have problems with the GLIBC_2.2.5
version and generate wrong package dependencies.

--
Florian Weimer / Red Hat Product Security Team
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Joseph Myers
In reply to this post by Kees Cook-2
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.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Mike Frysinger
In reply to this post by Kees Cook-2
On Wednesday 23 January 2013 00:26:02 Kees Cook wrote:
> On Tue, Jan 22, 2013 at 9:02 PM, Mike Frysinger <[hidden email]> wrote:
> > On Tuesday 22 January 2013 23:06:06 Kees Cook wrote:
> >> On Tue, Jan 22, 2013 at 7:34 PM, Mike Frysinger <[hidden email]>
wrote:

> >> > On Tuesday 22 January 2013 22:16:38 Joseph S. Myers wrote:
> >> >> On Tue, 22 Jan 2013, Kees Cook wrote:
> >> >> > This adds the new Linux finit_module() syscall.
> >> >>
> >> >> There's no point in adding syscalls to syscalls.list without at least
> >> >> adding a symbol version so the function is actually exported from
> >> >> libc.so. Note that in the kexec_load discussion last May / June,
> >> >> doubts were expressed about whether some existing module-related
> >> >> syscalls really should have had functions in glibc.
> >> >
> >> > the lack of a header file that exports prototypes for these functions
> >> > seems like bad form too (not a new issue to finit_module)
> >>
> >> I got the impression those were auto-generated from syscalls.list
> >> (which contains the prototype in an encoded for ("i:isi" in
> >> finit_module's case). And that this generation is what converts the
> >> syscall into return value and errno?
> >
> > syscalls.list auto generates the simple funcs in glibc that are glorified
> > syscall() calls, but they don't (afaik) generate headers.  grepping
> > installed glibc headers doesn't show any match that i can see either.
>
> Yeah, seems true. Weird. The callers (e.g. kmod) use their own externs.
> Hmpf
libkmod/libkmod-module.c:extern long init_module(const void *mem, unsigned
long len, const char *args);
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Mike Frysinger
In reply to this post by Florian Weimer-5
On Wednesday 23 January 2013 03:36:11 Florian Weimer wrote:

> On 01/23/2013 06:26 AM, 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?
>
> I think RPM-based distributions will have problems with the GLIBC_2.2.5
> version and generate wrong package dependencies.
err, no
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Mike Frysinger
In reply to this post by Joseph Myers
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

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Joseph Myers
On Wed, 23 Jan 2013, Mike Frysinger wrote:

> > 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).

I don't think the kexec_load discussion completely settled the issue.  
Perhaps someone would like to list what architecture-independent syscalls
in current kernels do not have glibc wrappers, excluding syscalls that are
clearly obsolete and only for backwards compatibility and should never be
used by new programs?  Then we can see how big the issue is.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

David Miller-13
From: "Joseph S. Myers" <[hidden email]>
Date: Wed, 23 Jan 2013 17:59:28 +0000

> On Wed, 23 Jan 2013, Mike Frysinger wrote:
>
>> > 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).
>
> I don't think the kexec_load discussion completely settled the issue.  
> Perhaps someone would like to list what architecture-independent syscalls
> in current kernels do not have glibc wrappers, excluding syscalls that are
> clearly obsolete and only for backwards compatibility and should never be
> used by new programs?  Then we can see how big the issue is.

FWIW my vote is for GLIBC to provide a bonafide interface, as well as a header
declaration, for these syscalls.

We get into trouble, like the double definitions of "struct in6_addr"
et al.  in netinet/in.h vs. the kernel header, exactly because glibc's
support for kernel provided interfaces is sometimes out of sync or
missing completely.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Roland McGrath-4
> We get into trouble, like the double definitions of "struct in6_addr"
> et al.  in netinet/in.h vs. the kernel header, exactly because glibc's
> support for kernel provided interfaces is sometimes out of sync or
> missing completely.

That kind of case really doesn't speak to the issue at hand.  We're talking
here about arcane syscalls that no normal program uses at all.  There is no
part of the related kernel interface that we'd declare in libc headers.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Kees Cook-2
On Wed, Jan 23, 2013 at 10:36 AM, Roland McGrath <[hidden email]> wrote:
>> We get into trouble, like the double definitions of "struct in6_addr"
>> et al.  in netinet/in.h vs. the kernel header, exactly because glibc's
>> support for kernel provided interfaces is sometimes out of sync or
>> missing completely.
>
> That kind of case really doesn't speak to the issue at hand.  We're talking
> here about arcane syscalls that no normal program uses at all.  There is no
> part of the related kernel interface that we'd declare in libc headers.

I think it's entirely sensible to define an interface to
(f)init_module. It seems sloppy to require a program to use syscall()
for a known interface.

As for other missing syscalls, at least kcmp comes to mind.

-Kees

--
Kees Cook
Chrome OS Security
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

David Miller-13
From: Kees Cook <[hidden email]>
Date: Wed, 23 Jan 2013 11:29:25 -0800

> On Wed, Jan 23, 2013 at 10:36 AM, Roland McGrath <[hidden email]> wrote:
>>> We get into trouble, like the double definitions of "struct in6_addr"
>>> et al.  in netinet/in.h vs. the kernel header, exactly because glibc's
>>> support for kernel provided interfaces is sometimes out of sync or
>>> missing completely.
>>
>> That kind of case really doesn't speak to the issue at hand.  We're talking
>> here about arcane syscalls that no normal program uses at all.  There is no
>> part of the related kernel interface that we'd declare in libc headers.
>
> I think it's entirely sensible to define an interface to
> (f)init_module. It seems sloppy to require a program to use syscall()
> for a known interface.
>
> As for other missing syscalls, at least kcmp comes to mind.

I completely agree with Kees.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

Roland McGrath-4
This is both ignoring and rehashing the previous discussion on this topic,
while not adding any new arguments.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add finit_module syscall for Linux

David Miller-13
From: Roland McGrath <[hidden email]>
Date: Wed, 23 Jan 2013 12:54:34 -0800 (PST)

> This is both ignoring and rehashing the previous discussion on this topic,
> while not adding any new arguments.

It makes no sense for every tool that wants to support
doing things with kernel modules to do the syscall()
thing, propagating potential errors in argument signatures
into more than one location instead of getting it right in
one canonical place, libc.
12