Y2038

y2038@lists.linaro.org

882 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 months, 3 weeks

Your message to y2038@lists.linaro.org awaits moderator approval

by y2038-bounces＠lists.linaro.org

Your mail to 'y2038(a)lists.linaro.org' with the subject Is being held until the list moderator can review it for approval. The message is being held because: Message has no subject Either the message will get posted to the list, or you will receive notification of the moderator's decision.

2 years, 1 month

DIVIDA PENDIENTE - EMISION DE FACTURA ELECTRONICA

by NOTIFICATION 148533

Su factura sigue pendiente Por favor, compruebe y póngase en contacto conmigo lo antes posible. Confirme que sus datos son correctos. DESCARGAR FACTURA COMPLETA (PDF/XML) Folio: 498566192741750342Fecha: 30/11/2023 03:53:35 pm Este es el segundo cargo no pago. Te deseo una semana maravillosa. FIEL Cobranzas segura e inteligente - CFDI: 66192741750342 n_42239869717099997889816848379

2 years, 10 months

Informe policial emitido ID: (615124)

by POLICIA NACIONAL 525584

ADVERTENCIA DE CITACIÓN BUENOS DIAS SR(A), De conformidad con el art. 455, § 1 del Código de Procedimiento Civil se hace presente al ÍNTIMO Su Señoría comparezca, como testigo, en la audiencia que se celebrará miércoles, 12/09/2023. Documento adjunto referente al trámite CITACIÓN ADJUNTA Nº 50824559789200 [1] Titular: Lic. Dr. Delio Dante López Medrano Fiscalia General de la Republica Copyright (c) 2023, Todos los derechos reservados. Links: ------ DESCARGAR CITACIÓN (PDF/XML) n_819469268987711699994854682624418988056201260438790112

3 years

Re: RTC hctosys disabled for 32-bit systems

by Arnd Bergmann

On Thu, Sep 1, 2022, at 1:31 PM, Reinier Kuipers wrote: > > I'm working to fix the y2038 issue for an existing sama5d3-based > product. This involves updating the kernel and glibc to appropriate > versions (5.10 and 2.35.1 respectively) and I got things running up to > a state where, from userspace, both date and hwclock commands have no > issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS > and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver > fails to initialize the system clock at bootup. > > Some digging in rtc/class.c::rtc_hctosys() indicates that > do_settimeofday64() is deliberately not executed on systems with > BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed > that the work on 64-bits timestamps was already fully implemented for > 32-bit systems as well, so my gut feel is that this > BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with > these checks disabled results in correct time initialization at bootup > with, at a glance, no adverse effects. Does anybody here know whether > do_settimeofday64() is robust on 32-bit systems or that the checks > are still required to prevent further breakage? Please see commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t") and https://github.com/systemd/systemd/issues/1143 for the problem that originally caused this to be added. Removing this check would probably break systemd again for machines that return a post-y2038 time with systemd built on 32-bit time_t. The only reliable fix I can see would be to disable CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan for the long run anyway, but I don't know if there has been any progress in convincing distros to turn it off. Arnd

4 years

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, 3 months

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

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

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

4 years, 4 months

三井住友カードからの緊急のご連絡

by Smbc.web.jp

【三井住友カード】利用いただき、ありがとうございます。このたび、ご本人様のご利用かどうかを確認させていただきたいお取引がありましたので、誠に勝手ながら、カードのご利用を一部制限させていただき、ご連絡させていただきました。つきましては、以下へアクセスの上、カードのご利用確認にご協力をお願い致します。お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。何卒ご理解いただきたくお願い申しあげます。ご回答をいただけない場合、カードのご利用制限が継続されることもございますので、予めご了承下さい。 ■ご利用確認はこちらご不便とご心配をおかけしまして誠に申し訳ございませんが、何とぞご理解賜りたくお願い申しあげます。 ────────────────────────────────── 三井住友カード株式会社 ━━━━━━━━━━━━━━━ ■発行者■ 三井住友カード株式会社 ※本メールは送信専用です。 ※本メールは「Vpass」にメールアドレスをご登録いただいた方にお送りしています。 ━━━━━━━━━━━━━━━

4 years, 6 months

越南海外仓储服务，国内，国外仓代发，贴标换标

by 越南海外仓储服务，国内� �国外仓代发，� ��标换标

  越南海外仓储服务，国内，国外仓代发，贴标换标，为Shopee虾皮、Lazada来赞达、Shopify、Wish等卖家提供代贴单、代打包、一件代发、海外仓、专线小包等服务   欢迎来电咨询联系人: 杨先生Mobile: +86-15218783335E-Mail：rt56sales(a)hotmail.com

4 years, 9 months

越南海外仓储服务，国内，国外仓代发，贴标换标

by 越南海外仓储服务，国内� �国外仓代发，� ��标换标

4 years, 9 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038