Y2038 May 2022

y2038@lists.linaro.org

14 participants
14 discussions

[PATCH 1/7] timekeeping: consolidate timekeeping_inject_offset code

by Arnd Bergmann

The code to check the adjtimex() or clock_adjtime() arguments is spread out across multiple files for presumably only historic reasons. As a preparatation for a rework to get rid of the use of 'struct timeval' and 'struct timespec' in there, this moves all the portions into kernel/time/timekeeping.c and marks them as 'static'. The warp_clock() function here is not as closely related as the others, but I feel it still makes sense to move it here in order to consolidate all callers of timekeeping_inject_offset(). Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- include/linux/time.h | 26 ---------- kernel/time/ntp.c | 61 ---------------------- kernel/time/ntp_internal.h | 1 - kernel/time/time.c | 36 +------------ kernel/time/timekeeping.c | 123 ++++++++++++++++++++++++++++++++++++++++++++- kernel/time/timekeeping.h | 2 +- 6 files changed, 123 insertions(+), 126 deletions(-) diff --git a/include/linux/time.h b/include/linux/time.h index 9bc1f945777c..c0fbad08448f 100644 --- a/include/linux/time.h +++ b/include/linux/time.h @@ -134,32 +134,6 @@ static inline bool timeval_valid(const struct timeval *tv) extern struct timespec timespec_trunc(struct timespec t, unsigned gran); -/* - * Validates if a timespec/timeval used to inject a time offset is valid. - * Offsets can be postive or negative. The value of the timeval/timespec - * is the sum of its fields, but *NOTE*: the field tv_usec/tv_nsec must - * always be non-negative. - */ -static inline bool timeval_inject_offset_valid(const struct timeval *tv) -{ - /* We don't check the tv_sec as it can be positive or negative */ - - /* Can't have more microseconds then a second */ - if (tv->tv_usec < 0 || tv->tv_usec >= USEC_PER_SEC) - return false; - return true; -} - -static inline bool timespec_inject_offset_valid(const struct timespec *ts) -{ - /* We don't check the tv_sec as it can be positive or negative */ - - /* Can't have more nanoseconds then a second */ - if (ts->tv_nsec < 0 || ts->tv_nsec >= NSEC_PER_SEC) - return false; - return true; -} - /* Some architectures do not supply their own clocksource. * This is mainly the case in architectures that get their * inter-tick times by reading the counter on their interval diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c index edf19cc53140..a5e702669d84 100644 --- a/kernel/time/ntp.c +++ b/kernel/time/ntp.c @@ -653,67 +653,6 @@ static inline void process_adjtimex_modes(struct timex *txc, } - -/** - * ntp_validate_timex - Ensures the timex is ok for use in do_adjtimex - */ -int ntp_validate_timex(struct timex *txc) -{ - if (txc->modes & ADJ_ADJTIME) { - /* singleshot must not be used with any other mode bits */ - if (!(txc->modes & ADJ_OFFSET_SINGLESHOT)) - return -EINVAL; - if (!(txc->modes & ADJ_OFFSET_READONLY) && - !capable(CAP_SYS_TIME)) - return -EPERM; - } else { - /* In order to modify anything, you gotta be super-user! */ - if (txc->modes && !capable(CAP_SYS_TIME)) - return -EPERM; - /* - * if the quartz is off by more than 10% then - * something is VERY wrong! - */ - if (txc->modes & ADJ_TICK && - (txc->tick < 900000/USER_HZ || - txc->tick > 1100000/USER_HZ)) - return -EINVAL; - } - - if (txc->modes & ADJ_SETOFFSET) { - /* In order to inject time, you gotta be super-user! */ - if (!capable(CAP_SYS_TIME)) - return -EPERM; - - if (txc->modes & ADJ_NANO) { - struct timespec ts; - - ts.tv_sec = txc->time.tv_sec; - ts.tv_nsec = txc->time.tv_usec; - if (!timespec_inject_offset_valid(&ts)) - return -EINVAL; - - } else { - if (!timeval_inject_offset_valid(&txc->time)) - return -EINVAL; - } - } - - /* - * Check for potential multiplication overflows that can - * only happen on 64-bit systems: - */ - if ((txc->modes & ADJ_FREQUENCY) && (BITS_PER_LONG == 64)) { - if (LLONG_MIN / PPM_SCALE > txc->freq) - return -EINVAL; - if (LLONG_MAX / PPM_SCALE < txc->freq) - return -EINVAL; - } - - return 0; -} - - /* * adjtimex mainly allows reading (and writing, if superuser) of * kernel time-keeping variables. used by xntpd. diff --git a/kernel/time/ntp_internal.h b/kernel/time/ntp_internal.h index d8a7c11fa71a..74b52cd48209 100644 --- a/kernel/time/ntp_internal.h +++ b/kernel/time/ntp_internal.h @@ -7,7 +7,6 @@ extern void ntp_clear(void); extern u64 ntp_tick_length(void); extern ktime_t ntp_get_next_leap(void); extern int second_overflow(time64_t secs); -extern int ntp_validate_timex(struct timex *); extern int __do_adjtimex(struct timex *, struct timespec64 *, s32 *); extern void __hardpps(const struct timespec64 *, const struct timespec64 *); #endif /* _LINUX_NTP_INTERNAL_H */ diff --git a/kernel/time/time.c b/kernel/time/time.c index 44a8c1402133..04684e294f00 100644 --- a/kernel/time/time.c +++ b/kernel/time/time.c @@ -158,40 +158,6 @@ SYSCALL_DEFINE2(gettimeofday, struct timeval __user *, tv, } /* - * Indicates if there is an offset between the system clock and the hardware - * clock/persistent clock/rtc. - */ -int persistent_clock_is_local; - -/* - * Adjust the time obtained from the CMOS to be UTC time instead of - * local time. - * - * This is ugly, but preferable to the alternatives. Otherwise we - * would either need to write a program to do it in /etc/rc (and risk - * confusion if the program gets run more than once; it would also be - * hard to make the program warp the clock precisely n hours) or - * compile in the timezone information into the kernel. Bad, bad.... - * - * - TYT, 1992-01-01 - * - * The best thing to do is to keep the CMOS clock in universal time (UTC) - * as real UNIX machines always do it. This avoids all headaches about - * daylight saving times and warping kernel clocks. - */ -static inline void warp_clock(void) -{ - if (sys_tz.tz_minuteswest != 0) { - struct timespec adjust; - - persistent_clock_is_local = 1; - adjust.tv_sec = sys_tz.tz_minuteswest * 60; - adjust.tv_nsec = 0; - timekeeping_inject_offset(&adjust); - } -} - -/* * In case for some reason the CMOS clock has not already been running * in UTC, but in some local time: The first time we set the timezone, * we will warp the clock so that it is ticking UTC time instead of @@ -224,7 +190,7 @@ int do_sys_settimeofday64(const struct timespec64 *tv, const struct timezone *tz if (firsttime) { firsttime = 0; if (!tv) - warp_clock(); + timekeeping_warp_clock(); } } if (tv) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 8af77006e937..679dbfbea419 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1300,13 +1300,39 @@ int do_settimeofday64(const struct timespec64 *ts) } EXPORT_SYMBOL(do_settimeofday64); +/* + * Validates if a timespec/timeval used to inject a time offset is valid. + * Offsets can be postive or negative. The value of the timeval/timespec + * is the sum of its fields, but *NOTE*: the field tv_usec/tv_nsec must + * always be non-negative. + */ +static inline bool timeval_inject_offset_valid(const struct timeval *tv) +{ + /* We don't check the tv_sec as it can be positive or negative */ + + /* Can't have more microseconds then a second */ + if (tv->tv_usec < 0 || tv->tv_usec >= USEC_PER_SEC) + return false; + return true; +} + +static inline bool timespec_inject_offset_valid(const struct timespec *ts) +{ + /* We don't check the tv_sec as it can be positive or negative */ + + /* Can't have more nanoseconds then a second */ + if (ts->tv_nsec < 0 || ts->tv_nsec >= NSEC_PER_SEC) + return false; + return true; +} + /** * timekeeping_inject_offset - Adds or subtracts from the current time. * @tv: pointer to the timespec variable containing the offset * * Adds or subtracts an offset value from the current time. */ -int timekeeping_inject_offset(struct timespec *ts) +static int timekeeping_inject_offset(struct timespec *ts) { struct timekeeper *tk = &tk_core.timekeeper; unsigned long flags; @@ -1345,7 +1371,40 @@ int timekeeping_inject_offset(struct timespec *ts) return ret; } -EXPORT_SYMBOL(timekeeping_inject_offset); + +/* + * Indicates if there is an offset between the system clock and the hardware + * clock/persistent clock/rtc. + */ +int persistent_clock_is_local; + +/* + * Adjust the time obtained from the CMOS to be UTC time instead of + * local time. + * + * This is ugly, but preferable to the alternatives. Otherwise we + * would either need to write a program to do it in /etc/rc (and risk + * confusion if the program gets run more than once; it would also be + * hard to make the program warp the clock precisely n hours) or + * compile in the timezone information into the kernel. Bad, bad.... + * + * - TYT, 1992-01-01 + * + * The best thing to do is to keep the CMOS clock in universal time (UTC) + * as real UNIX machines always do it. This avoids all headaches about + * daylight saving times and warping kernel clocks. + */ +void timekeeping_warp_clock(void) +{ + if (sys_tz.tz_minuteswest != 0) { + struct timespec adjust; + + persistent_clock_is_local = 1; + adjust.tv_sec = sys_tz.tz_minuteswest * 60; + adjust.tv_nsec = 0; + timekeeping_inject_offset(&adjust); + } +} /** * __timekeeping_set_tai_offset - Sets the TAI offset from UTC and monotonic @@ -2290,6 +2349,66 @@ ktime_t ktime_get_update_offsets_now(unsigned int *cwsseq, ktime_t *offs_real, } /** + * ntp_validate_timex - Ensures the timex is ok for use in do_adjtimex + */ +static int ntp_validate_timex(struct timex *txc) +{ + if (txc->modes & ADJ_ADJTIME) { + /* singleshot must not be used with any other mode bits */ + if (!(txc->modes & ADJ_OFFSET_SINGLESHOT)) + return -EINVAL; + if (!(txc->modes & ADJ_OFFSET_READONLY) && + !capable(CAP_SYS_TIME)) + return -EPERM; + } else { + /* In order to modify anything, you gotta be super-user! */ + if (txc->modes && !capable(CAP_SYS_TIME)) + return -EPERM; + /* + * if the quartz is off by more than 10% then + * something is VERY wrong! + */ + if (txc->modes & ADJ_TICK && + (txc->tick < 900000/USER_HZ || + txc->tick > 1100000/USER_HZ)) + return -EINVAL; + } + + if (txc->modes & ADJ_SETOFFSET) { + /* In order to inject time, you gotta be super-user! */ + if (!capable(CAP_SYS_TIME)) + return -EPERM; + + if (txc->modes & ADJ_NANO) { + struct timespec ts; + + ts.tv_sec = txc->time.tv_sec; + ts.tv_nsec = txc->time.tv_usec; + if (!timespec_inject_offset_valid(&ts)) + return -EINVAL; + + } else { + if (!timeval_inject_offset_valid(&txc->time)) + return -EINVAL; + } + } + + /* + * Check for potential multiplication overflows that can + * only happen on 64-bit systems: + */ + if ((txc->modes & ADJ_FREQUENCY) && (BITS_PER_LONG == 64)) { + if (LLONG_MIN / PPM_SCALE > txc->freq) + return -EINVAL; + if (LLONG_MAX / PPM_SCALE < txc->freq) + return -EINVAL; + } + + return 0; +} + + +/** * do_adjtimex() - Accessor function to NTP __do_adjtimex function */ int do_adjtimex(struct timex *txc) diff --git a/kernel/time/timekeeping.h b/kernel/time/timekeeping.h index d0914676d4c5..44aec7893cdd 100644 --- a/kernel/time/timekeeping.h +++ b/kernel/time/timekeeping.h @@ -10,7 +10,7 @@ extern ktime_t ktime_get_update_offsets_now(unsigned int *cwsseq, extern int timekeeping_valid_for_hres(void); extern u64 timekeeping_max_deferment(void); -extern int timekeeping_inject_offset(struct timespec *ts); +extern void timekeeping_warp_clock(void); extern int timekeeping_suspend(void); extern void timekeeping_resume(void); -- 2.9.0

2 days, 19 hours

Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

by Arnd Bergmann

On 17/05/2022 09:51, Arnaud Panaïotis wrote: > Hello, > > I'm working for a client to generate embedded 32-bits Linux Kernel working after y2038 issue. > > I generated a 5.15 Kernel thought Buildroot with Coreutils 9.0, GCC 11.2.0, Binutils 2.37, Glibc 2.34-9 and CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64. > > I encounter an issue while working with OpenSSH (I initially contacted them before). To clarify: did you build just openssh with -D_TIME_BITS=64, or did you build the user space this way? > After 2038, /usr/sbin/sshd does not create an error but it child does generate this one: > daemon() failed: Value too large for defined data type > > This happend here in sshd.c: > > 2019 /* > 2020 * If not in debugging mode, not started from inetd and not already > 2021 * daemonized (eg re-exec via SIGHUP), disconnect from the controlling > 2022 * terminal, and fork. The original process exits. > 2023 */ > 2024 already_daemon = daemonized(); > 2025 if (!(debug_flag || inetd_flag || no_daemon_flag || already_daemon)) { > 2026 > 2027 if (daemon(0, 0) == -1) > 2028 fatal("daemon() failed: %.200s", strerror(errno)); My guess is that there are parts of glibc that are not fully y2038-safe at the moment, but merely provide the interfaces for time64 applications. In the glibc code, I see int daemon (int nochdir, int noclose) { ... if ((fd = __open_nocancel(_PATH_DEVNULL, O_RDWR, 0)) != -1 && (__builtin_expect (__fstat64 (fd, &st), 0) == 0)) { ... } else { __close_nocancel_nostatus (fd); return -1; } return (0); } __fstatat64 (int fd, const char *file, struct stat64 *buf, int flags) { struct __stat64_t64 st_t64; return __fstatat64_time64 (fd, file, &st_t64, flags) ?: __cp_stat64_t64_stat64 (&st_t64, buf); } If I'm reading this correctly, daemon() internally uses the time32 version of 'stat', which fails for files with out-of-range timestamps. Are you able to rebuild the ssh binary (or your entire distro, if that's easier) against musl-1.2.x instead of glibc to see if the same thing happens there? Arnd > To reproduce: > > # date -s "2040-05-12" > # hwclock --systohc > # reboot > # /usr/sbin/sshd > > Note this error occurs only after the reboot, and setting a date before 2038 also require a reboot to remove the error. > > strace and gdb trace linked. > > Let me know if you need additional information.

4 years, 1 month

大陆出口香港运输，大量接敏感货，液体，口罩，试剂盒，化工品，食品等

by 大陆出口香港运输，大量� �敏感货，液体� ��口罩，试剂盒，化工品，食� �等

  大陆出口香港运输，大量接敏感货液体，口罩，试剂盒，化工品，食品等  ■  大陆上门提货，运输报关一条龙服务 ■  香港可提供装卸货，拼箱，仓储服务 ■  九龙/新界/港岛派送公司以及仓库 ■  香港机场/仓码头仓入仓服务联系我们联系人：JackMobile ：+86-13642980935 (微信同号）E-mail : wuliu56sales01(a)hotmail.com

4 years, 1 month

专注澳洲新西兰太平洋群岛

by 专注澳洲 � �西兰太平洋群岛

优势航线    全国各沿海口岸┈┈┈┈→ 澳洲  新西兰  南太平洋群岛所有港口   作为多家船公司的代理，海展与多家船公司密切配合。      专营优势      1.全国各港口到澳大利亚    澳东基本港：悉尼、墨尔本、布里斯班    澳西基本港：费力曼特尔、阿德莱德     2.全国各港口到新西兰    新西兰基本港：奥克兰、利特尔顿、纳皮尔、陶朗加     3.全国各港口到南太平洋群岛    PORT MORESBY、LAE、SUVA、LAUTOKA、HONIARA、PAPEETE、SAIPAN、GUAM 、MADANG、KIMBE、MALE等    服务范围    服务网络覆盖全中国及东南亚各主要港口直出澳洲新西兰和南太平洋群岛的海运服务     服务优势专注澳新航线十五年国内各大船东签约代理一手价格，拒绝中间商省时·省钱·省力一步到位联系方式：18923766646    邮件：sales01(a)smartsh.com.cn  qq:1034907910

4 years, 1 month

For product details

by Carl

Hi, We are interested in testing your product for an article, video and review in CeroLag.You can contact me WeChat Carl20190526. We remain pending. Greetings

4 years, 1 month

专注澳洲，新西兰，太平洋群岛因为专一，所以专一

by 专注澳洲，新西兰，太平� �群岛因为专� �，所以专一

               ●专注澳洲，新西兰，太平洋群岛    ●因为专一，所以专一！一、多年专注澳洲、新西兰航线及太平洋偏港航线运营，航位保障，高素质的专业服务团队，为客户提供专业的全方位服务。二、完善的进出口代理网络，快速派送送门服务，满足各种海空运进出口货物的托运需求，为你顺利完成EXW,CIF,FOB,DDU,DDP 等业务提供绝对保障。三、承接平板、框架、开顶、冻柜、散杂船等特种柜等多玩化业务。四、依托“一带一路”政策，我司已成功拓展东南亚各港口（新加坡，马来西亚，胡志明等港口）直出澳洲业务。联系方式：18923766646    邮件：sales01(a)smartsh.com.cn  QQ:1034907910

4 years, 1 month

Amazon.co.jp にご登録のアカウント（名前、パスワード、その他個人情報）

by amazon.co.jp

できるだけ早くアカウントにログインして、個人の住所や携帯電話の情報を確認してください。アカウントが正しく機能していることを確認してください。サインイン試行アクティビティ詳細を表示します利用規約プライバシー規約ヘルプ ? 1996-2022, Amazon.com, Inc.or its affiliates

4 years, 1 month

专业运输电池产品，纯电池和内置电池产品---大陆出口香港运输

by 专业运输电池产品，纯电� �和内置电池产� ��---专业大陆出� �香港运输

  大陆出口香港运输专业运输电池产品  ■  大陆上门提货，运输报关一条龙服务 ■  香港可提供装卸货，拼箱，仓储服务 ■  九龙/新界/港岛派送公司以及仓库 ■  香港机场/仓码头仓入仓服务联系我们联系人：JackMobile ：+86-13642980935 (微信同号）E-mail : wuliu56sales01(a)hotmail.com

4 years, 1 month

专注澳洲新西兰太平洋群岛

by 专注澳洲 � �西兰太平洋群岛

4 years, 1 month

中國大陸淘寶-天貓-電商-京東等貨--集運--直達香港運輸

by 中國大陸淘寶-天貓-電商-京� ��等貨--集運--直� ��香港運輸

  你好    本公司主營中國大陸淘寶商城，天貓商城，電商貨,京東商城等各大商城---集運--直達香港運輸，    時效：今發明至,（提供快遞單號，貨物名稱，重量，體積，件數，即可發貨，操作簡單）   可提供,拍照,驗貨,貼嘜頭,換紙箱等附加服務聯繫人:楊先生電話:86-13642980935 (微信同號)E-mail:hk13642980935@hotmail.com

4 years, 1 month

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038 May 2022