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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Kees Cook]

On Tue, Mar 27, 2012 at 10:21 AM, Ted Ts'o <ty...@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

[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

[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

[Kees Cook]

On Tue, Mar 27, 2012 at 10:37 AM, Ted Ts'o <ty...@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

[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

[Kees Cook]

On Thu, Mar 29, 2012 at 10:58 AM, H. Peter Anvin <h...@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

[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