Creating tracking bugzilla for the glibc changes which are required as part of the keyring support for MSDW. Refer to bug #130914 for description of the kernel portion. This change is to represent the new error codes and system call interfaces for the kernel key management facility need backporting from FC to RHEL4.
add_key etc. aren't exported from libc.so, and as they weren't exported until 2.3.5 release, they can't be exported as GLIBC_2.3.5 or earlier symver. If they aren't added to 2.3.6, then they'd need to be GLIBC_2.4 symbols (provided they are exported in CVS HEAD), but those symbols aren't appropriate for RHEL4 nor FC{3,4}, otherwise rpm would happily install programs needing other @GLIBC_2.4 symbols on RHEL4, but of course RHEL4 glibc can't provide them. With the sys_errlist array it is tricky. It is exported as an array, not as say a pointer to an array or something like that. Therefore, if binaries use sys_errlist, they end up with a copy relocation and sys_errlist then lives in their .bss section. But obviously copy relocation needs to know the size of the array. ATM we do very ugly tricks, so that the various sys_errlist symbols have the same base address in libc.so, but different sizes: 200: 00cbd700 504 OBJECT GLOBAL DEFAULT 27 sys_errlist@@GLIBC_2.3 530: 00cbd700 492 OBJECT GLOBAL DEFAULT 27 sys_errlist 965: 00cbd700 500 OBJECT GLOBAL DEFAULT 27 sys_errlist The addition of those new errno codes would need another version, so suddenly programs that use sys_errlist linked on RHEL4 U2 would not run on RHEL4 U1.
The sys_errlist problem is not very nice. How can a program cope with getting error codes beyond those listed in the array? I take it that it will just get a bad pointer. If so, that means you can't use an old glibc with a kernel that might return any higher error code if the program in question uses sys_errlist. Is there nothing in the userspace programming environment that indicates the size of sys_errlist[]? Not that anything would necessarily pay attention to it if it does exist...
On the subject of relocations on sys_errlist... _why_ does the executable need to copy the sys_errlist[] array into its bss section at all? If a shared library uses it and the executable doesn't, that shared library accesses it directly out of glibc's data using a R_X86_64_GLOB_DAT or similar. Why does the executable have to use a R_X86_64_COPY relocation? It can certainly use R_X86_64_GLOB_DAT for other things, and it only needs the address... This business of copying things to the executable's bss seems to cause problems for backwards incompatibility, and it does seem to be unnecessary.
If you compile the executable code with -fpic/-fPIC, then sure, no copy relocation is needed. But otherwise it is, as the address of sys_errlist needs to be known at static link time (well, there is -Wl,-z,nocopyreloc but that results in DT_TEXTREL binaries and that is both undesirable and SELinux policy will usually refuse to even start such binaries).
Why? I still don't see why it's necessary. Is this to avoid having to fix up the read-only/text segment of the executable?
Yes, of course. That is both costly (startup time, the code can't be shared anymore between different processes) and a security risk (if kernel can't forbid making the code writable, because the dynamic linker must write to it, then an exploit can make it writable too).
And I stress again, I don't think any glibc code should be added. It is not necessary to export this functionality to 3rd part apps. All the utilities we ship which need to handle these new syscalls can use the syscall() function and define their own constants. We _might_ add the interfaces for RHEL5 but there is no good reason to cause incompatibilities in the lifetime of RHEL4.
glibc-2.3.90-23 and later define the error codes in an asm/errno.h header prepended before the standard one (#include_next <asm/errno.h> #ifndef ENOKEY #define ENOKEY ... ... #endif ). So even the strings should be there.