linux-kernel - Clocksource: should the read() function of a clocksource be NMI safe?

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>] [day] [month] [year] [list]

Message-ID: <CAGzjT4c54TJA__dcx43745JKeZPeYQ3siowR66j0-KFe=EMRCA@mail.gmail.com>
Date:   Mon, 20 Jun 2022 23:24:47 +0200
From:   Jaccon Bastiaansen <jaccon.bastiaansen@...il.com>
To:     daniel.lezcano@...aro.org, Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org
Subject: Clocksource: should the read() function of a clocksource be NMI safe?

Hello all,

The ktime_get_*_fast_ns() functions in kernel/time/timekeeping.c are
listed as NMI safe.

If I am correct, the implementation of these functions uses the read()
function of the currently selected clocksource.

But a potential lockup can occur if this read() function uses a raw
spinlock. A running read() function can be interrupted by an NMI which
also calls the read() function. The NMI handler will then spin forever
in an attempt to lock an already locked raw spinlock.

Is my reasoning correct? Should the read() function of a clocksource
always be NMI safe? This requirement is not documented and I see that
several clocksource drivers (such as drivers/clocksource/i8253.c) are
not NMI safe (they lock a raw spinlock in their read() function).

Regards,
   Jaccon Bastiaansen