linux-kernel - Re: Question about ktime_get_mono_fast

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJD7tkayXxKEPpRE7QvBN4CikqeQcUe3_qfrUaH4V+cJrk0y=Q@mail.gmail.com>
Date:   Thu, 13 Oct 2022 20:25:40 -0700
From:   Yosry Ahmed <yosryahmed@...gle.com>
To:     John Stultz <jstultz@...gle.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, Hao Luo <haoluo@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>
Subject: Re: Question about ktime_get_mono_fast_ns() non-monotonic behavior

On Thu, Oct 13, 2022 at 7:39 PM John Stultz <jstultz@...gle.com> wrote:
>
> On Mon, Sep 26, 2022 at 2:18 PM Yosry Ahmed <yosryahmed@...gle.com> wrote:
> >
> > I have a question about ktime_get_mono_fast_ns(), which is used by the
> > BPF helper bpf_ktime_get_ns() among other use cases. The comment above
> > this function specifies that there are cases where the observed clock
> > would not be monotonic.
> >
> > I had 2 beginner questions:
>
> Thinking about this a bit more, I have my own "beginner question": Why
> does bpf_ktime_get_ns() need to use the ktime_get_mono_fast_ns()
> accessor instead of ktime_get_ns()?
>
> I don't know enough about the contexts that bpf logic can run, so it's
> not clear to me and it's not obviously commented either.

I am not the best person to answer this question (the BPF list is
CC'd, it's full of more knowledgeable people).

My understanding is that because BPF programs can basically be run in
any context (because they can attach to almost all functions /
tracepoints in the kernel), the time accessor needs to be safe in all
contexts.

Now that I know that ktime_get_mono_fast_ns() can drift significantly,
I am wondering why we don't just read sched_clock(). Can the
difference between sched_clock() on different cpus be even higher than
the potential drift from ktime_get_mono_fast_ns()?

>
> Looking at some of the uses of ktime_get_mono_fast_ns() spread around
> the kernel, some are clearly necessary (trying to get timestamps in
> suspend paths after timekeeping might be shutdown, etc). But there's
> also a few cases where the need isn't clear and I'm worried the
> reasoning is because it says "fast" in its name.
>   "Why stop with ktime_get_mono_fast_ns() when you could instead use
> ktime_get_real_fast()! It's *real fast*!" :)
>
> thanks
> -john