Messages in this thread | | | Date | Tue, 21 Mar 2023 13:44:36 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 8/8] selftests/proc: Assert clock_gettime(CLOCK_BOOTTIME) VS /proc/uptime monotonicity |
| |
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.
| |