* Correct way to include siginfo.h?
@ 2012-03-27 17:01 Kees Cook
2012-03-27 17:21 ` Ted Ts'o
0 siblings, 1 reply; 8+ messages in thread
From: Kees Cook @ 2012-03-27 17:01 UTC (permalink / raw)
To: LKML
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Correct way to include siginfo.h?
2012-03-27 17:01 Correct way to include siginfo.h? Kees Cook
@ 2012-03-27 17:21 ` Ted Ts'o
2012-03-27 17:29 ` Kees Cook
0 siblings, 1 reply; 8+ messages in thread
From: Ted Ts'o @ 2012-03-27 17:21 UTC (permalink / raw)
To: Kees Cook; +Cc: LKML
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Correct way to include siginfo.h?
2012-03-27 17:21 ` Ted Ts'o
@ 2012-03-27 17:29 ` Kees Cook
2012-03-27 17:37 ` Ted Ts'o
0 siblings, 1 reply; 8+ messages in thread
From: Kees Cook @ 2012-03-27 17:29 UTC (permalink / raw)
To: Ted Ts'o, Kees Cook, LKML
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Correct way to include siginfo.h?
2012-03-27 17:29 ` Kees Cook
@ 2012-03-27 17:37 ` Ted Ts'o
2012-03-27 18:01 ` Kees Cook
0 siblings, 1 reply; 8+ messages in thread
From: Ted Ts'o @ 2012-03-27 17:37 UTC (permalink / raw)
To: Kees Cook; +Cc: LKML
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Correct way to include siginfo.h?
2012-03-27 17:37 ` Ted Ts'o
@ 2012-03-27 18:01 ` Kees Cook
2012-03-29 17:58 ` H. Peter Anvin
0 siblings, 1 reply; 8+ messages in thread
From: Kees Cook @ 2012-03-27 18:01 UTC (permalink / raw)
To: Ted Ts'o, Kees Cook, LKML
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Correct way to include siginfo.h?
2012-03-27 18:01 ` Kees Cook
@ 2012-03-29 17:58 ` H. Peter Anvin
2012-03-29 18:13 ` Kees Cook
0 siblings, 1 reply; 8+ messages in thread
From: H. Peter Anvin @ 2012-03-29 17:58 UTC (permalink / raw)
To: Kees Cook; +Cc: Ted Ts'o, LKML
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Correct way to include siginfo.h?
2012-03-29 17:58 ` H. Peter Anvin
@ 2012-03-29 18:13 ` Kees Cook
2012-03-29 18:14 ` H. Peter Anvin
0 siblings, 1 reply; 8+ messages in thread
From: Kees Cook @ 2012-03-29 18:13 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Ted Ts'o, LKML
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-03-29 18:14 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-27 17:01 Correct way to include siginfo.h? Kees Cook
2012-03-27 17:21 ` Ted Ts'o
2012-03-27 17:29 ` Kees Cook
2012-03-27 17:37 ` Ted Ts'o
2012-03-27 18:01 ` Kees Cook
2012-03-29 17:58 ` H. Peter Anvin
2012-03-29 18:13 ` Kees Cook
2012-03-29 18:14 ` H. Peter Anvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox