On Tue, Nov 27, 2012 at 10:17:13AM +0000, Markos Chandras wrote: > On 26 November 2012 20:32, Rich Felker <[email protected]> wrote: > > > > As far as I know, there's nothing to maintain "backwards > > compatibility" with. The stat structures vary per-arch, and an arch > > that doesn't have a non-64-bit statfs syscall doesn't have an existing > > "struct statfs" to maintain backwards compatibility with. You can just > > define "struct statfs" to match the layout of the 64-bit struct. > > I see what you mean but looking at the uClibc code > (include/bits/statfs.h) struct statfs is always > defined so your proposal of introducing yet another statfs for arches > that don't have the non-64bit > syscalls will conflict with this definition. It's always possible to > #if/#endif the existing statfs structure with a new one > for architectures that don't have the 32-bit version, but I don't > think this is prettier to what I've done here. > Same thing happens in the the kernel. A statfs structure is always > exported whether you can support the > 32-bit syscall or not. Also existing applications expect this > well-known struct statfs. Changing it to a new one will > result in an ABI break.
The claim of "ABI break" is nonsense. There is presently NO WAY to use this legacy stat structure on no-legacy-syscall kernels. So there is no way anything could be using it. Really, on no-legacy-syscall kernels, _FILE_OFFSET_BITS should always be 64 and the legacy structs should not even exist. But if you insist on providing them anyway, you should use the same layout as the 64-bit struct that the syscall supports, rather than writing nasty bloat to convert to a completely non-native legacy structure that has nothing to do with the kernel. > > By the way, the old small-off_t functions are supposed to give an > > error if any off_t value does not fit in the range of off_t, rather > > than silently truncating. So even if you want to keep the conversion > > code, you need to check this. If using my approach (with same struct > > layout and padding for the extra 32 bits), you'd need to test that the > > padding is zero and return an error if any nonzero value appeared in > > the padding (except perhaps in the case of -1?). > > > >> As for the simple "buf" pointer check, I think you missed the point. > >> This pointer is never passed to the kernel > >> (it is not passed to the INLINE_SYSCALL macro) so the kernel does not > >> know about it. It is possible your userspace > >> program to pass an invalid "buf" pointer and the INLINE_SYSCALL to > >> succeed but you will crash after that when you try > >> to dereference any member of the invalid "buf" pointer. > > > > Crashing is perfectly acceptable behavior. statfs() is under no > > obligation to report EFAULT; passing an invalid pointer is undefined > > behavior and the expected result should be a crash or worse. Even if > > the kernel handles it, passing bogus pointers won't necessarily give > > EFAULT; if they happen to point to writable memory, you'll just > > clobber random memory. > > > > Rich > > Well yeah, it just feels weird for your userspace application to be > able to crash your C library, Um, no, it's always possible. strlen((char *)1); Invalid pointers are always invalid, period. There is nothing you can do to protect stupid people against their own stupid use of invalid pointers. > although, as you correctly pointed out, it will not handle bad > possitive pointers. There is no such thing as a "positive pointer". Pointers do not have sign. > Normally the kernel would handle bad user input but in this case the > kernel has no > idea about it. No, the kernel will only tell you when the pointed-to memory is not mapped at all or mapped read-only. If the pointer happens to point to some random location that is writable, you'll just horribly trash your program's state; the kernel cannot warn you about this or protect you from it. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
