linux-kernel - Re: [PATCH] rust: time: Seal the ClockSource trait

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: <20250619.203319.1745503493999032815.fujita.tomonori@gmail.com>
Date: Thu, 19 Jun 2025 20:33:19 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: a.hindborg@...nel.org
Cc: fujita.tomonori@...il.com, boqun.feng@...il.com, alex.gaynor@...il.com,
 ojeda@...nel.org, aliceryhl@...gle.com, anna-maria@...utronix.de,
 bjorn3_gh@...tonmail.com, dakr@...nel.org, frederic@...nel.org,
 gary@...yguo.net, jstultz@...gle.com, linux-kernel@...r.kernel.org,
 lossin@...nel.org, lyude@...hat.com, rust-for-linux@...r.kernel.org,
 sboyd@...nel.org, tglx@...utronix.de, tmgross@...ch.edu
Subject: Re: [PATCH] rust: time: Seal the ClockSource trait

On Thu, 19 Jun 2025 11:31:08 +0200
Andreas Hindborg <a.hindborg@...nel.org> wrote:

> "FUJITA Tomonori" <fujita.tomonori@...il.com> writes:
> 
>> On Wed, 18 Jun 2025 21:13:07 +0200
>> Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>>> "Boqun Feng" <boqun.feng@...il.com> writes:
>>>
>>>> On Tue, Jun 17, 2025 at 05:10:42PM -0700, Boqun Feng wrote:
>>>>> On Wed, Jun 18, 2025 at 08:20:53AM +0900, FUJITA Tomonori wrote:
>>>>> > Prevent downstream crates or drivers from implementing `ClockSource`
>>>>> > for arbitrary types, which could otherwise leads to unsupported
>>>>> > behavior.
>>>>> >
>>>>>
>>>>> Hmm.. I don't think other impl of `ClockSource` is a problem, IIUC, as
>>>>> long as the ktime_get() can return a value in [0, i64::MAX). Also this
>>>>> means ClockSource should be an `unsafe` trait, because the correct
>>>>> implementaion relies on ktime_get() returns the correct value. This is
>>>>> needed even if you sealed ClockSource trait.
>>>>>
>>>>> Could you drop this and fix that the ClockSource trait instead? Thanks!
>>>>>
>>>>
>>>> For example:
>>>>
>>>>     /// Trait for clock sources.
>>>>     ///
>>>>     /// ...
>>>>     /// # Safety
>>>>     ///
>>>>     /// Implementers must ensure `ktime_get()` return a value in [0,
>>>>     //  KTIME_MAX (i.e. i64::MAX)).
>>>>     pub unsafe trait ClockSource {
>>>>         ...
>>>>     }
>>>
>>> Nice catch, it definitely needs to be unsafe. We should also require
>>> correlation between ID and the value fetched by `ktime_get`.
>>
>> What's ID?
> 
> 
>   pub trait ClockSource {
>       /// The kernel clock ID associated with this clock source.
>       ///
>       /// This constant corresponds to the C side `clockid_t` value.
>       const ID: bindings::clockid_t;
> 
> The constant used to identify the clock source when calling into C APIs.

Ah, I see. Sorry to ask another question, but can we require
correlation between ID and the value fetched by `ktime_get`? The value
fetched by ktime_get is opaque, isn't it?