Return-Path: thread-index: AcQVpAgJW0WOhxDEQ5+ZsLpN6EmCcg== Envelope-to: paul@sumlocktest.fsnet.co.uk Delivery-date: Sat, 03 Jan 2004 00:28:58 +0000 Message-ID: <008b01c415a4$080bd6f0$d100000a@sbs2003.local> Date: Mon, 29 Mar 2004 16:39:32 +0100 From: "Andi Kleen" To: Cc: , , , , Subject: Re: siginfo_t fracturing, especially for 64/32-bit compatibility mode In-Reply-To: <20040102194909.GA2990@rudolph.ccur.com> Content-Class: urn:content-classes:message References: <20040102194909.GA2990@rudolph.ccur.com> Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 29 Mar 2004 15:39:32.0781 (UTC) FILETIME=[0817BDD0:01C415A4] On Fri, 2 Jan 2004 14:49:09 -0500 Joe Korty 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/