Re: siginfo_t fracturing, especially for 64/32-bit compatibility mode

[Andi Kleen <ak@suse.de>]

On Fri, 2 Jan 2004 14:49:09 -0500
Joe Korty <joe.korty@ccur.com> wrote:

> siginfo_t processing is fragile when in 32 bit compatibility mode on
> a 64 bit processor.  The kernel does conversions between 32 and 64
> bit versions of siginfo_t and to do this, it must must always know
> which of the (unioned) fields of siginfo are actually being used.   I
> believe this is the original purpose of the si_code field -- the
> value in it should directly or indirectly indicate, unambigiously,
> which of the fields in siginfo_t hold useful values.
> 
> rt_sigqueueinfo(2) subverts this by reserving a range of si_code
> values for users, and there is nothing about them to indicate to the
> kernel which fields of siginfo_t are actually in use.  This is not a

My understanding was that the syscall always only supports si_int/si_ptr.
Only the kernel can pass other values.  The original idea was to
detect if the code comes from user space, the convert si_int/si_ptr,
otherwise do the kernel conversion.

More for compatibility the emulation layer has been copying the
rest of the 128byte siginfo too, but it didn't do any alignment
adjustment. So if somebody passes some arbitary structure
in there from user space it will likely only work if he sends
it to another 32bit or another 64bit process. Otherwise the alignment
will be messed up. There is nothing that can be done about them.

> A partial solution is to grep all uses of si_code in the kernel and
> in glibc and tailor the architecture-specific 64 <-> 32 bit siginfo
> kernel transform routines to current use.  But this is fragile as it
> does not take into account future glibc growth nor other users of
> rt_sigqueueinfo outside of glibc, such as applications invoking
> rt_sigqueueinfo directly.

Basically it was supposed to be: 

any signal queuing system calls: 
	reject any codes that can be generated by the kernel

conversion:
	if (code generated by the kernel)
		do appropiate conversion
	else
		fix si_int/si_ptr alignment and copy the rest


> 
> Worse, in 2.6.0 and glibc-2.3.2, there are conflicts in current
> si_code value assignments which affect both compatibility and native
> mode users.  When an application receives one of these siginfo_t's,
> it cannot in general determine why it got it or which fields in the
> siginfo_t it should extract and act upon.  And when in compatibility
> mode, the kernel cannot always determine which fields need to be
> converted and passed on.

If glibc uses other values than si_int/si_ptr for non kernel generated
signals it is IMHO broken.

> 
> The current conflicts are:

[...SI_TKILL, SI_ASYNCIO...] that's broken. We just cannot support that. This aspect of 
SuS just cannot be emulated in user space, glibc was misguided about attempting
it.

I think it is reasonable to just not support this in emulation. We should actually
reject these codes in sigqueueinfo when comming from user space.

-Andi