RTC plugin fixes and extension #419
Conversation
Factor out time_set() and time_get() for readability and reuse. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
|
@wkz could you have a look at the second commit in this PR? It should fix issue kernelkit/infix#794 -- I have tested it on an |
There was a problem hiding this comment.
This looks great! 💪
Potential Improvement
We could opt to always keep an RTC file when that has been enabled in the config - i.e., even when a real RTC is available.
If the time we read from the RTC is invalid, then we could use the file data as a fallback. This would improve the worst-case date offset for a device that has been gathering dust for a year, and whose super-cap has long since been drained.
In combination --with-rtc-date, that should ensure that the device always comes up with a date good enough to take care of most certificate ranges.
Thanks! 😃
Interesting idea! And, like you say, combined |
|
Alright, now it looks as follows if both RTC is bad and the system has no "save game" on disk yet: ... and when we have a bad RTC and working backup: |
This patch introduces a new configure option --with-rtc-file=FILE. When
enabled the RTC plugin detects missing RTC device and falls back to save
and restore system time from a file instead. When --with-rtc-file is
used without an argument the default file is /var/lib/misc/rtc, but the
feature itself is disabled by default.
The usefulness of this feature may not be obvious at first, but some
systems are equipped with an RTC that resets to a random date at power
on. This can be really bad in the case the date is far in the future,
because an NTP sync would then cause time skips backwards, which shows
up in logs and causes a whole lot of pain in alarm systems.
The solution is to disable the RTC driver or device tree node, and when
Finit starts up, the RTC plugin detects a the device node and instead
restores time from the last save game. Meaning time will always only
move forwards.
NOTE: when Finit is built --with-rtc-file we always save to disk, but
only restore from the "save game" if restoring from RTC fails.
If the system has no RTC we always restore from disk.
As an added bonus, this change also makes sure to periodically
sync also the RTC with the system clock. Useful for systems
that do not run an NTP client.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
In 42ef3d3, for v4.4-rc1, support for setting a custom RTC restore date was introduced. Unfortunately the configure script was wrong and caused config.h to contain #define RTC_TIMESTAMP_CUSTOM "$rtc_date" instead of #define RTC_TIMESTAMP_CUSTOM "2023-04-10 14:35:42" Furthermore, the error handling for strptime() was wrong, so the restore date was always reverted to the default. This patch fixes both issues and extends the DATE of --with-rtc-date to also include seconds. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
These plugins signal success and failure directly to the console, the user should inspect syslog for more information. This change is a follow-up to 340cae4, where kernel logs of LOG_ERR and higher are allowed to log directly to the console. Since syslogd has not been started before these plugins, the log messages would otherwise leak to the console. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This PR contains three major changes to the RTC plugin:
time_set()andtime_get()functions--with-rtc-datefixes, both configure script andstrpdate()error handling