IoT Edge 1.5 (Scarthgap) on STM32MP1 - inconsistent certificate timestamp conversion / check

[Yo-3k]

Hi!

I am currently trying to get meta-iotedge running on an STM32MP1 platform. I already have a working iotedge setup for my hardware using a Debian image with the matching derivate of iotedge. However, we are planning to switch long-term to Yocto for flexibility and OS customization possibilities.

For testing I am using a very basic poky-altcfg distro (due to the systemd requirement) with a custom image based on core-image-minimal. The image compiles without errors and iotedge is available in my distro, there are no iotedge related errors printed in dmesg or journalctl.

However, when I try to configure iotedge with my (know working) config.toml, I run into the issue that my aziot-edged-ca certificate instantly expires upon creation:

Jan 14 13:58:17 my-client aziot-edged[1478]: 2026-01-14T13:58:17Z [INFO] - Edge CA was renewed
Jan 14 13:58:17 my-client aziot-edged[1478]: 2026-01-14T13:58:17Z [ERR!] - Cert aziot-edged-ca is expired and could not  be renewed.
Jan 14 13:58:17 my-client aziot-edged[1478]: 2026-01-14T13:58:17Z [ERR!] - failed to configure Edge CA auto renew: Cert aziot-edged-ca is expired and could not be renewed

Using Yocto patches, I have been trying to track down the issue and found that function get_cert_chain() in cert-renewal/src/engine.rs actually reports a date expiration of the certificate! However, after trying to debug the code for a bit I have seen that the certificate timestamp conversion performed by crate::Time::from() seems to be inconsistent and produces bogus dates on the first call?

I added some lines to get_cert_chain() (engine.rs line 343ff):

let not_after = cert_chain[0].not_after();

// First conversion
let expiry1 = crate::Time::from(not_after);
log::error!("First conversion: {}", expiry1);

// Immediate second conversion with same reference
let expiry2 = crate::Time::from(not_after);
log::error!("Second conversion (same ref): {}", expiry2);

// Third conversion with fresh call
let expiry3 = crate::Time::from(cert_chain[0].not_after());
log::error!("Third conversion (fresh call): {}", expiry3);

// Fourth - repeat fresh call
let expiry4 = crate::Time::from(cert_chain[0].not_after());
log::error!("Fourth conversion (fresh call): {}", expiry4);

The resolut is an inconstant timestamp conversion:

Jan 14 14:34:20 my-client  aziot-edged[1170]: 2026-01-14T14:34:20Z [INFO] - Edge CA was renewed
Jan 14 14:34:20 my-client  aziot-edged[1170]: 2026-01-14T14:34:20Z [ERR!] - First conversion: -2330-08-31T06:03:56+00:00
Jan 14 14:34:20 my-client  aziot-edged[1170]: 2026-01-14T14:34:20Z [ERR!] - Second conversion (same ref): 2026-04-14T14:34:19+00:00
Jan 14 14:34:20 my-client  aziot-edged[1170]: 2026-01-14T14:34:20Z [ERR!] - Third conversion (fresh call): 2026-04-14T14:34:19+00:00
Jan 14 14:34:20 my-client  aziot-edged[1170]: 2026-01-14T14:34:20Z [ERR!] - Fourth conversion (fresh call): 2026-04-14T14:34:19+00:00
Jan 14 14:34:20 my-client  aziot-edged[1170]: 2026-01-14T14:34:20Z [ERR!] - Failed to calculate time difference.

With my debug code, the time conversion works from the second call on but then iotedge fails at a later point in time, probably also related to time conversion. I am not quite sure how to further debug this issue, maybe a specific flag is needed for the Rust compiler to properly support my platform?

[Yo-3k]

Update: When I inserted a debug print for tracing in impl std::convert::From<&openssl::asn1::Asn1TimeRef> for Time { } the timestamp conversion is also correct for the first function call. To me it looks like this issue is caused by something in the compiler / stack / context switch / cache. Maybe just a specific Rust compiler flag is missing for my STM32MP1 device?

[Yo-3k]

I have found the underlying issue, it is related to a linux time_t ABI mismatch between openssl and the rust libc rate.

Yocto based distributions have -D_TIME_BITS=64 set per default, addressing the Y2038 problem, which means that openssl is also compiled expecting 64-bit time_t.

However, the main branch of meta-iotedge uses a rust libc crate version not supporting 64-bit time_t on ARM32 causing the call ASN1_TIME_set(NULL, 0) in pub fn from_unix(time: time_t) -> Result<Asn1Time, ErrorStack> {} (asn1.rs) to pass 4 bytes for non riscv32 architecture ARM32 processors (like the STM32MP1 is). This is defined in the libc crate src/unix/linux_like/linux/gnu/b32/mod.rs. OpenSSL compiled with TIME_BITS=64 reads 8 bytes, getting garbage in the upper 32 bits. When I added debug prints or multiple calls of that API with rustc -opt-level=3 compiler flag, the stack seemingly was not cleared up on each function call causing non-garbage data to be present in the upper 32-bits.

Experimental 64-bit time support for the libc crate for non rscv32 32-bit ARM processors was added recently:
rust-lang/libc@739873b

To fix this, this meta layer needs to use a libc crate >= v0.2.179 and needs to properly set RUST_LIBC_UNSTABLE_GNU_TIME_BITS=64 once this libc feature is stable (see https://github.com/rust-lang/libc/releases/tag/0.2.179).

Until then, the workaround is to remove the "-D_TIME_BITS=64" "-D_FILE_OFFSET_BITS=64" CC flags in your Yocto distribution or remove the flags only for OpenSSL and packages that depend on OpenSSL.

[jlian]

Thanks for the excellent root cause analysis @Yo-3k

You're right that this is an upstream dependency issue. The libc crate version is pinned by the upstream Azure/iotedge and Azure/iot-identity-service repos' Cargo.lock files (currently at 0.2.153), so we can't bump it independently in this meta layer.

The proper fix requires:

1. Upstream IoT Edge / IIS updating libc to >= 0.2.179
2. The libc crate stabilizing the gnu_time_bits feature (currently experimental)
3. This layer setting RUST_LIBC_UNSTABLE_GNU_TIME_BITS=64 in the recipe environment

In the meantime, the workaround you described (removing -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 from OpenSSL or the affected recipes) is the right approach. For example, in a .bbappend:

# Work around ARM32 time_t ABI mismatch until libc >= 0.2.179
TARGET_CFLAGS:remove = "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"

We've added a note about this to the FAQ in the README. We'll track the upstream libc stabilization and apply the proper fix when it becomes available.