siginfo broken in glibc
Andreas Jaeger
aj@suse.de
Wed Jan 19 00:30:00 GMT 2000
>>>>> Chris Wing writes:
Chris> Andreas:
>> With the 32bit UID patches the siginfo type has been changed. But it
>> seems that this was always broken :-(.
>>
>> On ix86 and m68k, we've got the following struct as part of struct siginfo:
>> /* kill(). */
>> struct
>> {
>> __pid_t si_pid; /* Sending process ID. */
>> __uid_t si_uid; /* Real user ID of sending process. */
>> } _kill;
>>
>> Please note that __uid_t is 32bit. This worked before on a little
>> endian machine - by accident, I suppose.
Chris> Okay, I see what you are getting at. Are you saying that due to alignment,
Chris> the kernel structure has always had room for 32 bits, and glibc has always
Chris> picked up all 32 bits properly?
This is AFAIK true for ix86 - a chance for that platform wasn't
necessary. But it's not true for m68k.
Chris> If so, great, we'll just take out the _uid32 field in the kernel and
Chris> change si_uid to be the full 32 bit UID.
Chris> If not, then we can change the kernel structure to leave room for glibc's
Chris> (erroneous) padding.
Chris> Or are you saying that glibc's structure member _uid overlaps the next
Chris> field in some of the kernel structures?
On m68k it does - but this has never worked before, so just ignore it
- or let's synch those structures.
>> The kernel has now:
>> struct {
>> pid_t _pid; /* sender's pid */
>> old_uid_t _uid; /* backwards compatibility */
>> uid_t _uid32; /* sender's uid */
>> } _kill;
>>
>> Since the kernel delivers siginfo directly to the process without
>> going through glibc, this will break old programs. I don't see
>> directly a way to fix this so that a program using struct siginfo can
>> access the uid both under Linux 2.3.39+ and on older kernels.
Chris> That is the main problem. The only thing I can imagine is something
Chris> incredibly ugly like having glibc detect whether it is running on a old
Chris> kernel, and if so, catch all the signals itself and translate the
Chris> structures if it is running on an old kernel.
Chris> On the bright side, I don't think that there are many programs that use
Chris> real-time signals and pay attention to the uid field, so it may not be too
Chris> bad to break it now.
We should do it fast - but we should think good about it.
Chris> If glibc is broken (fields do not line up with the kernel), we are going
Chris> to have to break old applications anyway.
Exactly.
>> Please note that ix86 aligns on 32bit but m68k aligns on 16bit so that
>> the kernel and glibc declarations are different.
Chris> What about all the other architectures?
I'm not sure. Phil and Jakub: What's the alignment on Sparc32 and
Arm? Could you check what needs to be done for these architectures?
I'm preparing a patch for the kernel headers now to see if we can
settle the problem.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de
More information about the Libc-alpha
mailing list