Correct way to include siginfo.h?

Correct way to include siginfo.h?

[Kees Cook]

Hi,

Does anyone know the right way to include siginfo.h when building
userspace tools that need it?

Here are things that work:

#include <stdio.h>
#include <linux/signal.h>

or

#include <stdio.h>
#include <stdlib.h> // adding this breaks <linux/signal.h>
#include <asm/siginfo.h>

But the moment I need <signal.h>, things go badly due to glibc's
siginfo headers:

#include <stdio.h>
#include <signal.h>
#include <asm/siginfo.h>
...
/usr/include/asm-generic/siginfo.h:7:15: error: redefinition of ‘union sigval’
/usr/include/x86_64-linux-gnu/bits/siginfo.h:33:15: note: originally
defined here
...

If I use the attached patch (against the installed headers -- with
seccomp patches), I can do:

#include <asm/siginfo.h>
#include <signal.h>

But order matters, due to the #defines that libc wants to use. What's
the right way to get access to the kernel's siginfo structure
definition?

-Kees

--- /usr/include/asm-generic/siginfo.h~	2012-03-27 09:55:28.094751505 -0700
+++ /usr/include/asm-generic/siginfo.h	2012-03-27 09:57:06.368057279 -0700
@@ -4,10 +4,13 @@

 #include <linux/types.h>

+#ifndef __have_sigval_t
+# define __have_sigval_t
 typedef union sigval {
 	int sival_int;
 	void *sival_ptr;
 } sigval_t;
+#endif

 /*
  * This is the size (including padding) of the part of the
@@ -36,6 +39,8 @@
 #endif

 #ifndef HAVE_ARCH_SIGINFO_T
+#ifndef __have_siginfo_t
+#define __have_siginfo_t 1

 typedef struct siginfo {
 	int si_signo;
@@ -103,6 +108,7 @@
 /* If the arch shares siginfo, then it has SIGSYS. */
 #define __ARCH_SIGSYS
 #endif
+#endif

 /*
  * How these fields are to be accessed.
@@ -248,6 +254,8 @@
  * thread manager then catches and does the appropriate nonsense.
  * However, everything is written out here so as to not get lost.
  */
+#ifndef __have_sigevent_t
+#define __have_sigevent_t 1
 #define SIGEV_SIGNAL	0	/* notify via signal */
 #define SIGEV_NONE	1	/* other notification: meaningless */
 #define SIGEV_THREAD	2	/* deliver via thread creation */
@@ -283,5 +291,6 @@
 #define sigev_notify_function	_sigev_un._sigev_thread._function
 #define sigev_notify_attributes	_sigev_un._sigev_thread._attribute
 #define sigev_notify_thread_id	 _sigev_un._tid
+#endif

 #endif

-- 
Kees Cook
Chrome OS Security

Re: Correct way to include siginfo.h?

[Ted Ts'o]

On Tue, Mar 27, 2012 at 10:01:10AM -0700, Kees Cook wrote:
> 
> Does anyone know the right way to include siginfo.h when building
> userspace tools that need it?

What fields or structures are you trying to get at?  I haven't needed
to include siginfo.h explicitly even though this file pokes and prods
pretty thoroughly at the siginfo structures:

http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=e2fsck/sigcatcher.c;h=10b93287d5b2b4da1fb43d34fafd848d06c01645;hb=5f7c04972fefa8198c34f231a9e8a5430705b4ab

The sigcatcher.c file is a debugging tool for e2fsprogs that prints
pretty much everything that is available to userspace, as far as I
know...

						- Ted

Re: Correct way to include siginfo.h?

[Kees Cook]

On Tue, Mar 27, 2012 at 10:21 AM, Ted Ts'o <tytso@mit.edu> wrote:
> On Tue, Mar 27, 2012 at 10:01:10AM -0700, Kees Cook wrote:
>>
>> Does anyone know the right way to include siginfo.h when building
>> userspace tools that need it?
>
> What fields or structures are you trying to get at?  I haven't needed
> to include siginfo.h explicitly even though this file pokes and prods
> pretty thoroughly at the siginfo structures:

I'm trying to get at the future seccomp fields on siginfo_t, namely
"si_syscall":

static void reporter(int nr, siginfo_t *info, void *void_context)
{
...
    syscall = info->si_syscall;

> http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=e2fsck/sigcatcher.c;h=10b93287d5b2b4da1fb43d34fafd848d06c01645;hb=5f7c04972fefa8198c34f231a9e8a5430705b4ab
>
> The sigcatcher.c file is a debugging tool for e2fsprogs that prints
> pretty much everything that is available to userspace, as far as I
> know...

Yeah, it looks like you're leaning on glibc's signal.h (and its
bits/signal.h file), which has its own siginfo definition rather than
attempting to include one from the kernel.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: Correct way to include siginfo.h?

[Ted Ts'o]

On Tue, Mar 27, 2012 at 10:29:39AM -0700, Kees Cook wrote:
> 
> I'm trying to get at the future seccomp fields on siginfo_t, namely
> "si_syscall":

Ah, I didn't realize you were trying to do that.  siginfo_t has been
stable since forever, and so I think we've always depending on glibc
to export the structure.  As a result I don't know that much effort
has been made to make siginfo.h safe for any userspace user other than
glibc.

Silly question; we're not going to actually change the size of the
siginfo_t structure in a userspace visible way, are we?  I don't know
of are any shared libraries that fill in a siginfo_t structure passed
in by the caller (which could be located on the stack), but it's
certainly possible that such library ABI's could exist.

	  	   	     	     	   - Ted

Re: Correct way to include siginfo.h?

[Kees Cook]

On Tue, Mar 27, 2012 at 10:37 AM, Ted Ts'o <tytso@mit.edu> wrote:
> On Tue, Mar 27, 2012 at 10:29:39AM -0700, Kees Cook wrote:
>>
>> I'm trying to get at the future seccomp fields on siginfo_t, namely
>> "si_syscall":
>
> Ah, I didn't realize you were trying to do that.  siginfo_t has been
> stable since forever, and so I think we've always depending on glibc
> to export the structure.  As a result I don't know that much effort
> has been made to make siginfo.h safe for any userspace user other than
> glibc.
>
> Silly question; we're not going to actually change the size of the
> siginfo_t structure in a userspace visible way, are we?  I don't know
> of are any shared libraries that fill in a siginfo_t structure passed
> in by the caller (which could be located on the stack), but it's
> certainly possible that such library ABI's could exist.

No, siginfo, IIUC, is defined to be SI_MAX_SIZE bytes. The union for
seccomp (on SIGSYS) just uses a long and 2 ints. It'd be nice for
there to be a stable way to get the kernel's siginfo instead of
glibc's.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: Correct way to include siginfo.h?

[H. Peter Anvin]

On 03/27/2012 11:01 AM, Kees Cook wrote:
> 
> No, siginfo, IIUC, is defined to be SI_MAX_SIZE bytes. The union for
> seccomp (on SIGSYS) just uses a long and 2 ints. It'd be nice for
> there to be a stable way to get the kernel's siginfo instead of
> glibc's.
> 

Make it safe for the kernel to export and make glibc use the kernel's
version, just like everything else...

	-hpa

Re: Correct way to include siginfo.h?

[Kees Cook]

On Thu, Mar 29, 2012 at 10:58 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/27/2012 11:01 AM, Kees Cook wrote:
>>
>> No, siginfo, IIUC, is defined to be SI_MAX_SIZE bytes. The union for
>> seccomp (on SIGSYS) just uses a long and 2 ints. It'd be nice for
>> there to be a stable way to get the kernel's siginfo instead of
>> glibc's.
>>
>
> Make it safe for the kernel to export and make glibc use the kernel's
> version, just like everything else...

We'll have to poke the glibc folks. In the meantime, Will Drewry found
a stable way to handle this. Just make the first set of includes and
defines be:

#include <asm/siginfo.h>
#define __have_siginfo_t 1
#define __have_sigval_t 1
#define __have_sigevent_t 1

Then the glibc includes won't attempt the redefinition.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: Correct way to include siginfo.h?

[H. Peter Anvin]

On 03/29/2012 11:13 AM, Kees Cook wrote:
> 
> We'll have to poke the glibc folks. In the meantime, Will Drewry found
> a stable way to handle this. Just make the first set of includes and
> defines be:
> 

Well, "recent events" hopefully make that a bit easier.

	-hpa