On Monday 18 May 2015 12:16:48 Thorsten Glaser wrote:> Arnd Bergmann dixit: > > >In the patch series I posted recently [1], I introduce new system calls to deal > >with modified data structures, but left the question open on how these should > >be best accessed from libc. The patches introduce a new __kernel_time64_t type > > Can we please have ioctls fixed for mixed 32/64-bit systems > such as MIPS (o32/n32/n64) and x86 (i386/x32/amd64) first, > before even more such chance for breakage is introduced?It's hard because we don't even know what ioctls are affected at this point, and I was hoping to get this part merged as a stepping stone in the process of finding out. The problem is that there are so many different cases we have to worry about just for time_t: a) ioctls that pass a data structure from include/uapi/ with time_t and have a properly defined (using _IOW()/_IOR()/_IORW()) command number: these are easy enough to find and fix. b) ioctls that have a data structure as before but define their ioctl commands differently (e.g. using a literal number). I don't think we can fix them before we introduce the __KERNEL_TIME_BITS macro from my patch, because user space needs to see a different command number here, and we have a lot of these. c) ioctls that are defined ad-hoc, without any uapi header containing the structure, but using a proper _IOW()/_IOR()/_IORW() macro. These are much harder to find than a), but just as easy to fix d) ioctls that are defined ad-hoc based on a time_t value and with a wrong command number. These will be broken no matter what we do, and our only hope is to find all applications using them so we can fix the user space sources. e) ioctls that pass a time value as a 'long' or '__u32' instead of 'time_t'. Fixing them requires adding new ioctl commands to let them work beyond 2038, independent of what we do here. f) ioctls that use structures with pointers to other structures that are not defined in the uapi headers. (this might not be a problem, I haven't been able to figure out of these are real) All of the above are currently broken for x32, but fixing them will likely take a few years and leave x32 still broken because of other uses of __kernel_long_t in ioctl. MIPS on the other hand is no more broken than any of the other 32-bit ABIs, because it does not use 64-bit __kernel_long_t in its n32 ABI.> I still need to use an amd64 chroot on my x32 system to do > things such as set up iptables, because those ioctls break, > because they contain data structures that contain, well, > time types. Your proposal has a non-zero chance to bring > these issues to i386 (and other architectures).We should indeed not start widely deploying user space with 64-bit time_t on 32-bit architectures until we found and fixed a good part of the ioctls. My plan at this point is to eliminate all uses of time_t in the kernel and replace them with time64_t or other safe types. This way, we will eventually find all code that passes 32-bit time types to user space and can fix it. This will take care of the time_t related problems on x32 as well. Arnd
fup2p, this is offtopic for most lists Arnd Bergmann dixit:>It's hard because we don't even know what ioctls are affected at this point, >and I was hoping to get this part merged as a stepping stone in the process >of finding out.Oh okay.>e) ioctls that pass a time value as a 'long' or '__u32' instead of > 'time_t'. Fixing them requires adding new ioctl commands to let > them work beyond 2038, independent of what we do here.Yeah, that?s going to be fun.>MIPS on the other hand is no more broken than any of the other 32-bit >ABIs, because it does not use 64-bit __kernel_long_t in its n32 ABI.I have heard from a MIPS porter that one of the flavours suffers from similar problems as x32, just not to that extent. But I don?t recall my source?>ioctls. My plan at this point is to eliminate all uses of time_t in >the kernel and replace them with time64_t or other safe types. >This way, we will eventually find all code that passes 32-bit time types >to user space and can fix it. This will take care of the time_t >related problems on x32 as well.Ah, interesting approach. And existing userspace, as well as new userspace that does not declare 64-bit time_t readiness, is still safe on currently-not-broken architectures? So, there?s enough time to fix this before the various libcs turn that on (and it had better be fixed by then, because it becomes ABI by then). Nice idea. I am wondering a bit about the ioctls being hard to find. I have not much experience with kernel programming, and even less with Linux than with MS-DOS and BSD, but should not each driver have a central ioctl entry point, from which it should cast the user space data into a (possibly locally declared) structure? bye, //mirabilos -- <igli> exceptions: a truly awful implementation of quite a nice idea. <igli> just about the worst way you could do something like that, afaic. <igli> it's like anti-design. <mirabilos> that too? may I quote you on that? <igli> sure, tho i doubt anyone will listen ;)
On Monday 18 May 2015 17:03:08 Thorsten Glaser wrote:> >MIPS on the other hand is no more broken than any of the other 32-bit > >ABIs, because it does not use 64-bit __kernel_long_t in its n32 ABI. > > I have heard from a MIPS porter that one of the flavours suffers > from similar problems as x32, just not to that extent. But I > don?t recall my source?MIPS n32 has a lot of the same issues as x86 x32, but I'm pretty sure that the time_t one is not among them.> >ioctls. My plan at this point is to eliminate all uses of time_t in > >the kernel and replace them with time64_t or other safe types. > >This way, we will eventually find all code that passes 32-bit time types > >to user space and can fix it. This will take care of the time_t > >related problems on x32 as well. > > Ah, interesting approach. And existing userspace, as well as new > userspace that does not declare 64-bit time_t readiness, is still > safe on currently-not-broken architectures? So, there?s enough time > to fix this before the various libcs turn that on (and it had better > be fixed by then, because it becomes ABI by then). Nice idea.Correct. Another aspect of the approach I'm taking is that the system-call implementation is shared between the native 64-bit case and the new 32-bit case, while the handling for the existing syscalls on 32-bit architectures is shared with the 32-bit compat code on 64-bit architectures. This means if we introduce a bug in either of them, we will find out very quickly and don't have to wait until people start using 64-bit time_t on 32-bit user land.> I am wondering a bit about the ioctls being hard to find. I have > not much experience with kernel programming, and even less with > Linux than with MS-DOS and BSD, but should not each driver have > a central ioctl entry point, from which it should cast the user > space data into a (possibly locally declared) structure?Yes, that's how it works, but unfortunately we have a few thousand drivers that declare an ioctl function, and I hope to do something better than brute-force search all of them. The other point is that we really need to fix all y2038-related bug in drivers, not just the ones in ioctl. This includes things like file systems storing time in 32-bit units on disk, or drivers trying to measure how much time has elapsed without communicating that value elsewhere, but failing when the time_t number goes negative. Arnd