Y2038 compatibility #2038

ALTracer commented 2024年12月30日 15:48:53 +01:00 (Migrated from github.com)

Please clarify whether any BMP firmware platform or BMDA supported OS is affected by the Y2038 superbug.

1. BMP/STM32 does not use RTC peripherals, relies on newlib with 64-bit time_t (AFAIK) with arm-none-eabi-gcc from Arm GNU Tools. Do you need to ensure that the toolchain and/or libc is good? (in case someone tries to build against picolibc or NuttX libc etc.) Same for BMP/LM4F, and there are no other vendors among in-tree platforms.
2. BMP has Semihosting support. Does it pass timestamps (like SYS_TIME) around correctly? Does ARM semihosting ABI impose limitations on BMD?
3. BMP has rudimentary timekeeping for SysTick-based delays in milliseconds. When does this overflow and is this a problem?
4. BMDA when compiled for 32-bit OS has to rely on OS libc (glibc, musl, etc.) and kernel (vDSO) to provide time64_t; if time_t is 32-bit and BMDA compares timestamps, this is a potential problem. Are any mitigations required?
5. BMDA-supported 3rd party adapters are assumed to be unaffected because they don't retain datetime when unpowered or don't have to parse timestamps for pure USB/SWD/JTAG bridge manipulations. Is the BMP HL remote protocol affected?

Less sure about battery-powered ctxLink, Farpatch, etc. And 3rd party desktop software is not considered here, especially if they have their own issue trackers.

Please clarify whether any BMP firmware platform or BMDA supported OS is affected by the Y2038 superbug. 1. BMP/STM32 does not use RTC peripherals, relies on newlib with 64-bit time_t (AFAIK) with arm-none-eabi-gcc from Arm GNU Tools. Do you need to ensure that the toolchain and/or libc is good? (in case someone tries to build against picolibc or NuttX libc etc.) Same for BMP/LM4F, and there are no other vendors among in-tree platforms. 2. BMP has Semihosting support. Does it pass timestamps (like SYS_TIME) around correctly? Does ARM semihosting ABI impose limitations on BMD? 3. BMP has rudimentary timekeeping for SysTick-based delays in milliseconds. When does this overflow and is this a problem? 4. BMDA when compiled for 32-bit OS has to rely on OS libc (glibc, musl, etc.) and kernel (vDSO) to provide time64_t; if `time_t` is 32-bit and BMDA compares timestamps, this is a potential problem. Are any mitigations required? 5. BMDA-supported 3rd party adapters are assumed to be unaffected because they don't retain datetime when unpowered or don't have to parse timestamps for pure USB/SWD/JTAG bridge manipulations. Is the BMP HL remote protocol affected? Less sure about battery-powered ctxLink, Farpatch, etc. And 3rd party desktop software is not considered here, especially if they have their own issue trackers.

dragonmux commented 2024年12月31日 05:49:37 +01:00

👋🏼 going to answer each of the points in turn, though in practice the problem you're asking about is more a function of the semihosting protocol spec itself and what firmware being debugged supports (or doesn't):

BMP/STM32 does not use RTC peripherals, relies on newlib with 64-bit time_t (AFAIK) with arm-none-eabi-gcc from Arm GNU Tools. Do you need to ensure that the toolchain and/or libc is good? (in case someone tries to build against picolibc or NuttX libc etc.) Same for BMP/LM4F, and there are no other vendors among in-tree platforms.

We control for this by saying that other libc's are just unsupported as that's way too many variables to even begin to try and control in practice. If a user manages to even get a good build of the firmware out that way (which we currently doubt they would), then if they run into problems with 2038 then from the project's perspective, that's firmly on them for running an unsupported configuration. This is the only viable way we have to control for this.

BMP has Semihosting support. Does it pass timestamps (like SYS_TIME) around correctly? Does ARM semihosting ABI impose limitations on BMD?

On 32-bit targets, SYS_TIME is 32-bit, but it is unsigned, thus pushing the problem out past 2038. This is currently a problem we don't deal with properly under BMDA as we never got back to addressing the C API used to grab the time (never actually use time() in production code, it's fundamentally broken..) and which will be addressed in v2.1; but under the firmware we are constrained by GDB's correctness and as long as it gives us valid answers for the gettimeofday upcall, then the time representation structure we use internally will handle it just fine and even though we do an unsigned-signed conversion on the way out, the result will wind up correct in the MCU registers. This is contingent on things outside our control though.

BMP has rudimentary timekeeping for SysTick-based delays in milliseconds. When does this overflow and is this a problem?

It overflows every UINT32_MAX miliseconds, which is well defined by C. We then specifically take the overflow case into account in the timeout handling code. #1812 has more details about that. It used to be a problem and is a reason for people to migrate of their v1.x firmware once the release has been made of v2.0.

BMDA when compiled for 32-bit OS has to rely on OS libc (glibc, musl, etc.) and kernel (vDSO) to provide time64_t; if time_t is 32-bit and BMDA compares timestamps, this is a potential problem. Are any mitigations required?

In practice, this is only a problem on really ancient glibc's and such. All modern Linux distros have a time_t that is suitable. Meson also fixed a bug around this for us by passing -D_FILE_OFFSET_BITS=64 for all compilations automatically. There isn't an equivalent define for time_t that we know of, but we'll get what we can automatically. We're not aware of any timestamp comparisons made using anything other than internal unsigned structures and types.

BMDA itself uses gettimeofday() for the moment to get a suitable time value for timeouts and such. This calculation is carefully kept unsigned to prevent problems. It should give the same behaviour as the firmware's version with a counter.

BMDA-supported 3rd party adapters are assumed to be unaffected because they don't retain datetime when unpowered or don't have to parse timestamps for pure USB/SWD/JTAG bridge manipulations. Is the BMP HL remote protocol affected?

Yes, no time primitives exist in that protocol.

👋🏼 going to answer each of the points in turn, though in practice the problem you're asking about is more a function of the semihosting protocol spec itself and what firmware being debugged supports (or doesn't): > BMP/STM32 does not use RTC peripherals, relies on newlib with 64-bit time_t (AFAIK) with arm-none-eabi-gcc from Arm GNU Tools. Do you need to ensure that the toolchain and/or libc is good? (in case someone tries to build against picolibc or NuttX libc etc.) Same for BMP/LM4F, and there are no other vendors among in-tree platforms. We control for this by saying that other libc's are just unsupported as that's way too many variables to even begin to try and control in practice. If a user manages to even get a good build of the firmware out that way (which we currently doubt they would), then if they run into problems with 2038 then from the project's perspective, that's firmly on them for running an unsupported configuration. This is the *only* viable way we have to control for this. > BMP has Semihosting support. Does it pass timestamps (like SYS_TIME) around correctly? Does ARM semihosting ABI impose limitations on BMD? On 32-bit targets, [SYS_TIME](https://github.com/ARM-software/abi-aa/blob/main/semihosting/semihosting.rst#620sys_time-0x11) is 32-bit, but it is unsigned, thus pushing the problem out past 2038. This is [currently a problem](https://github.com/blackmagic-debug/blackmagic/blob/86704be968af4a8aa16e01a5f409e04028819391/src/target/semihosting.c#L702-L705) we don't deal with properly under BMDA as we never got back to addressing the C API used to grab the time (never actually use `time()` in production code, it's fundamentally broken..) and which will be addressed in v2.1; but under the firmware we are constrained by GDB's correctness and as long as it gives us [valid answers for the gettimeofday](https://github.com/blackmagic-debug/blackmagic/blob/86704be968af4a8aa16e01a5f409e04028819391/src/target/semihosting.c#L653) upcall, then the [time representation structure we use internally](https://github.com/blackmagic-debug/blackmagic/blob/86704be968af4a8aa16e01a5f409e04028819391/src/target/semihosting_internal.h#L62-L65) will handle it just fine and even though we do an unsigned-signed conversion on the way out, the result will wind up correct in the MCU registers. This is contingent on things outside our control though. > BMP has rudimentary timekeeping for SysTick-based delays in milliseconds. When does this overflow and is this a problem? It overflows every [UINT32_MAX miliseconds](https://github.com/blackmagic-debug/blackmagic/blob/86704be968af4a8aa16e01a5f409e04028819391/src/platforms/common/stm32/timing_stm32.c#L32), which is well defined by C. We then [specifically take the overflow case into account](https://github.com/blackmagic-debug/blackmagic/blob/86704be968af4a8aa16e01a5f409e04028819391/src/timing.c#L34-L43) in the timeout handling code. #1812 has more details about that. It used to be a problem and is a reason for people to migrate of their v1.x firmware once the release has been made of v2.0. > BMDA when compiled for 32-bit OS has to rely on OS libc (glibc, musl, etc.) and kernel (vDSO) to provide time64_t; if time_t is 32-bit and BMDA compares timestamps, this is a potential problem. Are any mitigations required? In practice, this is only a problem on really ancient glibc's and such. All modern Linux distros have a time_t that is suitable. Meson also fixed a bug around this for us by passing `-D_FILE_OFFSET_BITS=64` for all compilations automatically. There isn't an equivalent define for time_t that we know of, but we'll get what we can automatically. We're not aware of any timestamp comparisons made using anything other than internal unsigned structures and types. BMDA itself uses [`gettimeofday()` for the moment](https://github.com/blackmagic-debug/blackmagic/blob/86704be968af4a8aa16e01a5f409e04028819391/src/platforms/hosted/utils.c#L46-L51) to get a suitable time value for timeouts and such. This calculation is carefully kept unsigned to prevent problems. It should give the same behaviour as the firmware's version with a counter. > BMDA-supported 3rd party adapters are assumed to be unaffected because they don't retain datetime when unpowered or don't have to parse timestamps for pure USB/SWD/JTAG bridge manipulations. Is the BMP HL remote protocol affected? Yes, no time primitives exist in that protocol.