linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Wei Li <liwei391@huawei.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Yu Liao <liaoyu15@huawei.com>, Hillf Danton <hdanton@sina.com>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH 8/8] selftests/proc: Assert clock_gettime(CLOCK_BOOTTIME) VS /proc/uptime monotonicity
Date: Tue, 21 Mar 2023 13:44:36 +0100	[thread overview]
Message-ID: <ZBmmtMlKXcf2+hnq@lothringen> (raw)
In-Reply-To: <219c5d09-0099-83e9-b21b-299fa513decd@alu.unizg.hr>

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.


  reply	other threads:[~2023-03-21 12:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 14:46 [PATCH 0/8] timers/nohz: Fixes and cleanups v3 Frederic Weisbecker
2023-02-22 14:46 ` [PATCH 1/8] timers/nohz: Restructure and reshuffle struct tick_sched Frederic Weisbecker
2023-04-18 14:53   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2023-02-22 14:46 ` [PATCH 2/8] timers/nohz: Only ever update sleeptime from idle exit Frederic Weisbecker
2023-04-18 14:53   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2023-02-22 14:46 ` [PATCH 3/8] timers/nohz: Protect idle/iowait sleep time under seqcount Frederic Weisbecker
2023-04-18 14:53   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2023-02-22 14:46 ` [PATCH 4/8] timers/nohz: Add a comment about broken iowait counter update race Frederic Weisbecker
2023-04-18 14:53   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2023-02-22 14:46 ` [PATCH 5/8] timers/nohz: Remove middle-function __tick_nohz_idle_stop_tick() Frederic Weisbecker
2023-04-18 14:53   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2023-02-22 14:46 ` [PATCH 6/8] MAINTAINERS: Remove stale email address Frederic Weisbecker
2023-04-18 14:53   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2023-02-22 14:46 ` [PATCH 7/8] selftests/proc: Remove idle time monotonicity assertions Frederic Weisbecker
2023-04-18 14:53   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker
2023-02-22 14:46 ` [PATCH 8/8] selftests/proc: Assert clock_gettime(CLOCK_BOOTTIME) VS /proc/uptime monotonicity Frederic Weisbecker
2023-03-08 15:59   ` Mirsad Todorovac
2023-03-21 12:44     ` Frederic Weisbecker [this message]
2023-03-26 20:03       ` Mirsad Goran Todorovac
2023-04-18 14:53   ` [tip: timers/core] " tip-bot2 for Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZBmmtMlKXcf2+hnq@lothringen \
    --to=frederic@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=hdanton@sina.com \
    --cc=liaoyu15@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liwei391@huawei.com \
    --cc=mingo@kernel.org \
    --cc=mirsad.todorovac@alu.unizg.hr \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).