Messages in this thread | | | Date | Sun, 26 Mar 2023 22:03:56 +0200 | Subject | Re: [PATCH 8/8] selftests/proc: Assert clock_gettime(CLOCK_BOOTTIME) VS /proc/uptime monotonicity | From | Mirsad Goran Todorovac <> |
| |
On 21. 03. 2023. 13:44, Frederic Weisbecker wrote: > On Wed, Mar 08, 2023 at 04:59:41PM +0100, Mirsad Todorovac wrote: >> On 2/22/23 15:46, Frederic Weisbecker wrote: >> From what I see, you round the CLOCK_BOOTIME time to 1/100ths of a second. >> >> A simple program that queries clock_getres() on system clocks gives this >> result: >> >> clock_res [CLOCK_REALTIME] = 0.000000001s >> clock_res [CLOCK_REALTIME_COARSE] = 0.004000000s >> clock_res [CLOCK_MONOTONIC] = 0.000000001s >> clock_res [CLOCK_MONOTONIC_COARSE] = 0.004000000s >> clock_res [CLOCK_MONOTONIC_RAW] = 0.000000001s >> clock_res [CLOCK_BOOTTIME] = 0.000000001s >> clock_res [CLOCK_PROCESS_CPUTIME_ID] = 0.000000001s >> clock_res [CLOCK_THREAD_CPUTIME_ID] = 0.000000001s >> >> A number of programs may depend i.e. on CLOCK_REALTIME or CLOCK_BOOTIME to give >> different result each nanosecond. >> >> I came across this when generating nonces for HMACs according to recommendations >> from RFC 4086 "Randomness Requirements for Security". >> >> If the value of CLOCK_BOOTTIME or CLOCK_REALTIME is incremented not in what >> clock_getres() gives, but at best in 1/100th of second instead, that would seriously >> weaken our security (for as you know, in many cryptographic uses nonces need not >> be random, but MUST NOT ever repeat nor go backwards). >> >> Could we modify the test for this assumption, or is the assumption wrong? >> >> Here the test for CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID >> increasing monotonically with guaranteed increased value of nanoseconds >> would also seem good. >> >> Maybe this is already covered in another test case, but it seems that all >> clocks should be guaranteed to be monotonically increasing, and increased >> at least by one nanosecond with each syscall, or many algorithms would break. >> >> In other words, CLOCK_BOOTTIME should be tested to increase monotonically in >> the resolution given by clock_getres (CLOCK_BOOTTIME, &tv_res), not in 1/100ths >> of second (IMHO). > > Maybe but verifying a clock against its own resolution is another testcase. Here the > point is to verify that CLOCK_BOOTTIME is monotonic against /proc/uptime, and > since /proc/uptime has an 1/100 second resolution, rounding clock_gettime(CLOCK_BOOTTIME) > result down to that is the best we can do. > > Thanks.
Hi Frederic,
Thank you for explaining that.
I've read somewhere (forgot the link) that clock_gettime(CLOCK_*) clocks should be guaranteed to return at least a nanosecond increased value for a PID or TID from call to call.
Returning the same value would break some algorithms that depend on monotonous increase of time - for example, some naive implementations of nonce generators.
I believe this is worth assuring in tests, or possibly some naive crypto would reveal its pre-shared secrets in consecutive calls (Please see RFC 4086, "Randomness Requirements for Security" for greater detail in explanation.
Best regards, Mirsad
-- Mirsad Goran Todorovac Sistem inženjer Grafički fakultet | Akademija likovnih umjetnosti Sveučilište u Zagrebu System engineer Faculty of Graphic Arts | Academy of Fine Arts University of Zagreb, Republic of Croatia The European Union
| |