Y2038

y2038@lists.linaro.org

1 participants
1143 discussions

FWD: Summary of the 2038 BoF at DebConf 17

by Steve McIntyre

Hi folks, As discussed with Arnd, I ran a BoF session about Y2038 at DebConf last month, giving an overview of the problem and starting some discussion. Here's the write-up, and there's a link to the video of the session below. ----- Forwarded message from Steve McIntyre <steve(a)einval.com> ----- From: Steve McIntyre <steve(a)einval.com> To: debian-devel(a)lists.debian.org Date: Sat, 2 Sep 2017 00:58:54 +0100 Subject: Summary of the 2038 BoF at DC17 Hi folks, As promised, here's a quick summary of what was discussed at the 2038 BoF session I ran in Montréal. Thanks to the awesome efforts of our video team, the session is already online [1]. I've taken a copy of the Gobby notes too, alongside my small set of slides for the session. [2] We had a conversation about the coming End of The World, the 2038 problem. What's the problem? ------------------- UNIX time_t is 31 bits (signed), counting seconds since Jan 1, 1970. It's going to wrap. It's used *everywhere* in UNIX-based systems. Imagine the effects of Y2K, but worse. What could go wrong? -------------------- All kinds if disasters! We're not trying to exaggerate this *too* much, but it's likely to be a significat problem. For most of the things that needed fixing for Y2K, they were on big obvious computers, typically mainframes. Y2K was solved by people doing a lot of work; to many outside of the direct work, it almost came to be an anti-climax. In 20 years' time, the systems that we will be trying to fix for the 2038 problem are likely to be much harder to track. They're typically not even going to look like computers - look at the IoT devices available today, and extrapolate. Imagine all kinds of devices with embedded computers that we won't know how to talk to, let alone verify their software. When does it happen? -------------------- Pick the example from the date(1) man page: $ date --date=@$((2**31-1)) Tue 19 Jan 03:14:07 GMT 2038 At that point, lots of software will believe it's suddenly 1902... What needs doing? ----------------- Lots of fixes are going to be needed all the way up the stack. Data formats are often not 2038-safe. The filesystems in use today are typically not ready. Modern ext4 *is*, using 34 bits for seconds and 30 bits for nanoseconds. btrfs uses a 64-bit second counter. But data on older filesystems will need to be migrated. There are many places in the Linux kernel where 32-bit time_t is used. This is being worked on, and so are the interfaces that expose 32-bit time_t. Lots of libraries use 32-bit time_t, even in places where it might not be obvious. Finally, applications will need fixing. Linux kernel ------------ There's project underway to fix Linux time-handling, led by Deepa Dinamani and Arnd Bergmann. There's a web site describing the efforts at https://kernelnewbies.org/y2038 and a mailing list at y2038(a)lists.linaro.org. They are using the y2038 project as a good way to get new developers involved in the Linux kernel, and those people are working on fixing things in a number of areas: adding core 64-bit time support, fixing drivers, and adding new versions of interfaces (syscalls, ioctls). We can't just replace all the existing interfaces with 64-bit versions, of course - we need to continue suporting the existing interfaces for existing code. There are lots of tasks here where people can join in and help. Glibc ----- Glibc is the next obvious piece of the puzzle - almost everything depends on it. Planning is ongoing at https://sourceware.org/glibc/wiki/Y2038ProofnessDesign to provide 64-bit time_t support without breaking the existing 32-bit code. There's more coverage in LWN at https://lwn.net/Articles/664800/ The glibc developers are obviously going to need the kernel to provide 64-bit interfaces to make much progress. Again, there's lot of work to be done here and help will be welcome. Elsewhere? ---------- If you're working further up the stack, it's hard to make many fixes when the lower levels are not yet done. Kernels other than Linux are also going to have the same problems to solve - not really looked at them in much detail. As the old time_t interfaces are POSIX-specified, hopefully we'll get equivalent new 64-bit interfaces that will be standard across systems. Massive numbers of libraries are going to need updates, possibly more than people realise. Anything embedding a time_t will obviously need changing. However, many more structures will embed a timeval or timespec and they're also broken. Almost anything that embeds libc-exposed timing functions will need updating. We're going to need mass rebuilds to find things that break with new interfaces, and to ensure that old interfaces still work. An obvious thing to do here also is automated scanning for ABI compliance as things change. Things to do now ---------------- Firstly: developers trying to be *too* clever are likely to only make things worse - don't do it! Whatever you do in your code, don't bodge around the 32-bit time_t problem. *Don't* store time values in weird formats, and don't assume things about it to "avoid" porting problems. These are all going to cause pain in the future as we try to fix problems. For the time being in your code, *use* time_t and expect an ABI break down the road. This is the best plan *for now*. In terms of things like on-disk data structures, don't try to second-guess future interfaces by simply adding padding space for a 64-bit time_t or equivalent. The final solution for time handling may not be what you expect and you might just make things worse. Dive in and help the kernel and glibc folks if you can! Next, check your code and the dependencies of your code to see if there are any bodges or breakages that you *can* fix now. Discussion ---------- It's a shame to spoil the future pensions of people by trying to fix this problem early! :-) There are various license checkers already in use today - could the same technology help finding time junk? Similarly, are any of the static analysis tools likely to help. It's believed that Coverity (for example) may be looking into the static analysis component of this. There's plenty of scope for developers to help work in these areas too. Do we need to worry about *unsigned* time_t usage too (good to 2106)? As an example, OpenPGP packets use that. This gives us a little bit longer, but will still need to be considered. The main point to consider is fixing things *properly*, don't just hack around things by moving the epoch or something similarly short-term. It's important that we work on fixing issues *now* to stop people building broken things that will bite us. We all expect that our own computer systems will be fine by 2038; Debian systems will be fixed and working! We'll have rebuilt the world with new interfaces and found the issues. The issues are going to be in the IoT, with systems that we won't be able to simply rebuild/verify/test - they'll fail. We need to get the underlying systems right ASAP for those systems. 2038 is the problem we're looking at now, but we're going to start seeing issues well before then - think repeating calendar entries. Libraries often don't need to expose any time_t style information, but it's something to be careful about. If people have worked things out well, changing the internal implementation of a delay function should not pollute up the stack. But it's easy to pick up changes without realising - think about select() in the event loop, for example. Statically linked things (e.g. the Go ecosystem) are likely to bite - we need to make sure that the libraries that they embed are fixed early, before we can rebuild that stack upwards. How can we enforec the ability to upgrade and get support for IoT products so that they don't just brick themselves in future? GPL violations play into this because the sources are unavailable - i.e., no way to rebuild and upgrade. Ancient vendor kernels are a major PITA, and only make things more urgent. If you're designing your own data format without reference to current or upcoming standards, then of course consider the need for better time handling. Conversions will be needed anyway. Main takeaways: * This is a real problem * We need to fix the problem *early* * People are working on this already, and there's plenty of tasks to help with [1] http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/it-s-… [2] https://www.einval.com/~steve/talks/Debconf17-eotw-2038/ -- Steve McIntyre, Cambridge, UK. steve(a)einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead ----- End forwarded message ----- -- Steve McIntyre, Cambridge, UK. steve(a)einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer

8 years, 4 months

[PATCH 0/7] [media] y2038 conversion for subsystem

by Arnd Bergmann

Hi everyone, This is a conversion of all subsystem-wide v4l2 code to avoid the use of types based on time_t. The first five patches should all be harmless and obvious, so they can get applied for 4.3 after normal review. The last two patches are marked RFC for now because their possible impact on the user space ABI and to decide if this is the best approach or whether we should instead introduce extra code in the kernel to handle modified user space. There are a few device drivers beyond this series that rely on time_t/timeval/timespec internally, but they are all easy to fix and can be taken care of later. Arnd Arnd Bergmann (7): [media] dvb: use ktime_t for internal timeout [media] dvb: remove unused systime() function [media] dvb: don't use 'time_t' in event ioctl [media] exynos4-is: use monotonic timestamps as advertized [media] use v4l2_get_timestamp where possible [RFC] [media]: v4l2: introduce v4l2_timeval [RFC] [media] introduce v4l2_timespec type for timestamps drivers/media/dvb-core/demux.h | 2 +- drivers/media/dvb-core/dmxdev.c | 2 +- drivers/media/dvb-core/dvb_demux.c | 17 ++++++----------- drivers/media/dvb-core/dvb_demux.h | 4 ++-- drivers/media/dvb-core/dvb_net.c | 2 +- drivers/media/dvb-frontends/dibx000_common.c | 10 ---------- drivers/media/dvb-frontends/dibx000_common.h | 2 -- drivers/media/pci/bt8xx/bttv-driver.c | 7 ++----- drivers/media/pci/cx18/cx18-mailbox.c | 2 +- drivers/media/pci/meye/meye.h | 2 +- drivers/media/pci/zoran/zoran.h | 2 +- drivers/media/platform/coda/coda.h | 2 +- drivers/media/platform/exynos4-is/fimc-capture.c | 8 +------- drivers/media/platform/exynos4-is/fimc-lite.c | 7 +------ drivers/media/platform/omap/omap_vout.c | 4 ++-- drivers/media/platform/omap3isp/ispstat.c | 5 ++--- drivers/media/platform/omap3isp/ispstat.h | 2 +- drivers/media/platform/s3c-camif/camif-capture.c | 8 +------- drivers/media/platform/vim2m.c | 2 +- drivers/media/platform/vivid/vivid-ctrls.c | 2 +- drivers/media/usb/cpia2/cpia2.h | 2 +- drivers/media/usb/cpia2/cpia2_v4l.c | 2 +- drivers/media/usb/gspca/gspca.c | 6 +++--- drivers/media/usb/usbvision/usbvision.h | 2 +- drivers/media/v4l2-core/v4l2-common.c | 6 +++--- drivers/media/v4l2-core/v4l2-event.c | 20 +++++++++++++------- drivers/staging/media/omap4iss/iss_video.c | 5 +---- include/media/v4l2-common.h | 2 +- include/media/videobuf-core.h | 2 +- include/trace/events/v4l2.h | 12 ++++++++++-- include/uapi/linux/dvb/video.h | 3 ++- include/uapi/linux/omap3isp.h | 2 +- include/uapi/linux/videodev2.h | 16 ++++++++++++++-- 33 files changed, 79 insertions(+), 93 deletions(-) -- 2.1.0.rc2

8 years, 5 months

[PATCH 0/2] i/o: Make i/o y2038 safe

by Deepa Dinamani

This is a preparatory series to make i/o y2038-safe by replacing the use of struct timespec which is not y2038 safe by y2038 safe struct timespec64. Sockets and userspace interfaces themselves will be changed in a separate series. Deepa Dinamani (2): select: Use get/put_timespec64 io_getevents: Use timespec64 to represent timeouts fs/aio.c | 55 ++++++++++++++++++++++++++++++------------------------- fs/select.c | 60 ++++++++++++++++++++++++------------------------------------ 2 files changed, 54 insertions(+), 61 deletions(-) -- 2.11.0 Cc: linux-aio(a)kvack.org

8 years, 6 months

[PATCH v3 0/6] Make ipc y2038 safe

by Deepa Dinamani

The series aims to transition internal workings of ipc subsystem to use y2038-safe types and apis. The series is based on Al Viro's #work.ipc branch. Changes since v2: * Removed extra typecasts Changes since v1: * Addressed audit review comments Deepa Dinamani (6): ipc: Make sys_semtimedop() y2038 safe ipc: mqueue: Replace timespec with timespec64 ipc: msg: Make msg_queue timestamps y2038 safe ipc: sem: Make sem_array timestamps y2038 safe ipc: shm: Make shmid_kernel timestamps y2038 safe utimes: Make utimes y2038 safe fs/utimes.c | 23 ++++++++++++----------- include/linux/audit.h | 6 +++--- include/linux/msg.h | 7 ++++--- include/linux/sem.h | 3 ++- include/linux/shm.h | 6 +++--- include/linux/time.h | 2 +- init/initramfs.c | 2 +- ipc/mqueue.c | 28 ++++++++++++++-------------- ipc/msg.c | 6 +++--- ipc/sem.c | 30 +++++++++++++++--------------- ipc/shm.c | 10 +++++----- kernel/audit.h | 2 +- kernel/auditsc.c | 12 ++++++------ 13 files changed, 70 insertions(+), 67 deletions(-) -- 2.11.0 Cc: Paul Moore <paul(a)paul-moore.com> Cc: Richard Guy Briggs <rgb(a)redhat.com>

8 years, 6 months

[PATCH v2 0/6] Make ipc y2038 safe

by Deepa Dinamani

The series aims to transition internal workings of ipc subsystem to use y2038-safe types and apis. The series is based on Al Viro's #work.ipc branch. Changes since v1: * Addressed audit review comments Deepa Dinamani (6): ipc: Make sys_semtimedop() y2038 safe ipc: mqueue: Replace timespec with timespec64 ipc: msg: Make msg_queue timestamps y2038 safe ipc: sem: Make sem_array timestamps y2038 safe ipc: shm: Make shmid_kernel timestamps y2038 safe utimes: Make utimes y2038 safe fs/utimes.c | 23 ++++++++++++----------- include/linux/audit.h | 6 +++--- include/linux/msg.h | 7 ++++--- include/linux/sem.h | 3 ++- include/linux/shm.h | 6 +++--- include/linux/time.h | 2 +- init/initramfs.c | 2 +- ipc/mqueue.c | 28 ++++++++++++++-------------- ipc/msg.c | 12 ++++++------ ipc/sem.c | 34 +++++++++++++++++----------------- ipc/shm.c | 16 ++++++++-------- kernel/audit.h | 2 +- kernel/auditsc.c | 12 ++++++------ 13 files changed, 78 insertions(+), 75 deletions(-) -- 2.11.0

8 years, 6 months

[RESEND 0/6] Make ipc y2038 safe

by Deepa Dinamani

Resending to fix mail subject header. The series aims to transition internal workings of ipc subsystem to use y2038-safe types and apis. The series is based on Al Viro's #work.ipc branch. Deepa Dinamani (6): ipc: Make sys_semtimedop() y2038 safe ipc: mqueue: Replace timespec with timespec64 ipc: msg: Make msg_queue timestamps y2038 safe ipc: sem: Make sem_array timestamps y2038 safe ipc: shm: Make shmid_kernel timestamps y2038 safe utimes: Make utimes y2038 safe fs/utimes.c | 23 ++++++++++++----------- include/linux/audit.h | 6 +++--- include/linux/msg.h | 7 ++++--- include/linux/sem.h | 3 ++- include/linux/shm.h | 6 +++--- include/linux/time.h | 2 +- init/initramfs.c | 2 +- ipc/mqueue.c | 28 ++++++++++++++-------------- ipc/msg.c | 12 ++++++------ ipc/sem.c | 34 +++++++++++++++++----------------- ipc/shm.c | 16 ++++++++-------- kernel/audit.h | 2 +- kernel/auditsc.c | 12 ++++++------ 13 files changed, 78 insertions(+), 75 deletions(-) -- 2.11.0 Cc: Paul Moore <paul(a)paul-moore.com> Cc: Richard Guy Briggs <rgb(a)redhat.com>

8 years, 6 months

(no subject)

by Deepa Dinamani

Subject: [PATCH 0/6] Make ipc y2038 safe The series aims to transition internal workings of ipc subsystem to use y2038-safe types and apis. The series is based on Al Viro's #work.ipc branch. Deepa Dinamani (6): ipc: Make sys_semtimedop() y2038 safe ipc: mqueue: Replace timespec with timespec64 ipc: msg: Make msg_queue timestamps y2038 safe ipc: sem: Make sem_array timestamps y2038 safe ipc: shm: Make shmid_kernel timestamps y2038 safe utimes: Make utimes y2038 safe fs/utimes.c | 23 ++++++++++++----------- include/linux/audit.h | 6 +++--- include/linux/msg.h | 7 ++++--- include/linux/sem.h | 3 ++- include/linux/shm.h | 6 +++--- include/linux/time.h | 2 +- init/initramfs.c | 2 +- ipc/mqueue.c | 28 ++++++++++++++-------------- ipc/msg.c | 12 ++++++------ ipc/sem.c | 34 +++++++++++++++++----------------- ipc/shm.c | 16 ++++++++-------- kernel/audit.h | 2 +- kernel/auditsc.c | 12 ++++++------ 13 files changed, 78 insertions(+), 75 deletions(-) -- 2.11.0 Cc: Paul Moore <paul(a)paul-moore.com> Cc: Richard Guy Briggs <rgb(a)redhat.com>

8 years, 6 months

Components&PCBA on stop:169939

by King Song

y2038 NO. 1 components on-line shopping mall from China. COMPONENTS SOURCING, BOMs Kitting and PCB ASSEMBLY. We can reduce your project budget by HALF. We support components sourcing & BOMs kitting. We provides the latest new products from stock. We recommend you low costs, high quality components from China. We are PCBA Manufacturer and exporter in China. We have more than 10 years' experience in this field. All products can be offered with fast delivery and good quality control from small order to big volume order. We offer the following PCB assembly services: Quick-turn prototype assembly Turn-key assembly Partial turn-key assembly Consignment assembly RoHS compliant lead-free assembly Non-RoHS assembly Conformal coating Final box-build and packaging ________________________________________________________________________________________ We will reduce your costs by half. Any requests for components sourcing or PCB assembly?Please contact:King Song Dunfa Components Tel : 86-755-82544038 Fax : 86-755-23894043 Email : king(a)dunfa.com.cn Skype : philipsun8 no problem too big no BUSINESS too SMALL

8 years, 7 months

[PATCH v3 0/7] Isolate time_t data types for clock/timer syscalls

by Deepa Dinamani

The series aims at isolating data conversions of time_t based structures: struct timespec and struct itimerspec at user space boundaries. This helps to later change the underlying types to handle y2038 changes to these. The series is an update to Arnd Bergmann's previous series: http://sourceware.org/ml/libc-alpha/2015-05/msg00070.html Changes since v1: * Rebased and removed common code paths on the tip linux-next. Changes since v2: * Removed accidental inclusion of wrong version of patch 3/7. Deepa Dinamani (7): time: add get_timespec64 and put_timespec64 time: introduce {get,put}_itimerspec64 posix-stubs: Conditionally include COMPAT_SYS_NI defines posix-timers: Use get_timepsec64() and put_timespec64() nanosleep: Use get_timepsec64() and put_timespec64() timerfd: Use get_itimerspec64() and put_itimerspec64() posix_clocks: Use get_itimerspec64() and put_itimerspec64() fs/timerfd.c | 43 +++++++------ include/linux/compat.h | 6 ++ include/linux/hrtimer.h | 2 +- include/linux/posix-timers.h | 1 - include/linux/time.h | 18 ++++++ kernel/compat.c | 65 ++++++++++++++++++++ kernel/time/alarmtimer.c | 4 +- kernel/time/hrtimer.c | 30 ++++------ kernel/time/posix-cpu-timers.c | 8 +-- kernel/time/posix-stubs.c | 96 +++++++++++++++-------------- kernel/time/posix-timers.c | 133 +++++++++++++++-------------------------- kernel/time/time.c | 58 ++++++++++++++++++ 12 files changed, 287 insertions(+), 177 deletions(-) -- 2.11.0

8 years, 7 months

[PATCH v2 0/7] Isolate time_t data types for clock/timer syscalls

by Deepa Dinamani

The series aims at isolating data conversions of time_t based structures: struct timespec and struct itimerspec at user space boundaries. This helps to later change the underlying types to handle y2038 changes to these. The series is an update to Arnd Bergmann's previous series: http://sourceware.org/ml/libc-alpha/2015-05/msg00070.html Changes since v1: * Rebased and removed common code paths on the tip linux-next. Deepa Dinamani (7): time: add get_timespec64 and put_timespec64 time: introduce {get,put}_itimerspec64 posix-stubs: Conditionally include COMPAT_SYS_NI defines posix-timers: Use get_timepsec64() and put_timespec64() nanosleep: Use get_timepsec64() and put_timespec64() timerfd: Use get_itimerspec64() and put_itimerspec64() posix_clocks: Use get_itimerspec64() and put_itimerspec64() fs/timerfd.c | 43 +++++++------ include/linux/compat.h | 6 ++ include/linux/hrtimer.h | 2 +- include/linux/posix-timers.h | 1 - include/linux/time.h | 18 ++++++ kernel/compat.c | 65 ++++++++++++++++++++ kernel/time/alarmtimer.c | 4 +- kernel/time/hrtimer.c | 30 ++++------ kernel/time/posix-cpu-timers.c | 8 +-- kernel/time/posix-stubs.c | 99 ++++++++++++++++-------------- kernel/time/posix-timers.c | 133 +++++++++++++++-------------------------- kernel/time/time.c | 58 ++++++++++++++++++ 12 files changed, 289 insertions(+), 178 deletions(-) -- 2.11.0

8 years, 7 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038