linux-kernel - Re: [PATCH] drivers/cdrom: improved ioctl for media change detection

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2f78b2f4-e290-fb58-c097-0f2fdf781f02@kernel.dk>
Date:   Sat, 28 Aug 2021 07:22:20 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Lukas Prediger <lukas.prediger@...ip.de>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/cdrom: improved ioctl for media change detection

On 8/28/21 4:27 AM, Lukas Prediger wrote:
> Thanks for the reply and sorry for the spam :/. I am not sure what 
> happened there.
> 
>>> 2. As the last_media_change field will be in ms now, is it safe to
>>> convert those back to jiffies for comparison or is there a risk of
>>> information loss (due to rounding or whatever) in either conversion?
>>> More technically, can I make the assumption that for any jiffies value
>>> x it holds that
>> The granularity of jiffies depends on the HZ setting, generally just
>> consider it somewhere in between 100 and 1000. That's where my initial
>> granularity numbers came from.
>>
>>> time_before(msecs_to_jiffies(jiffies_to_msecs(x)), x) is always false ?
>> I don't think that matters. Internally, always keep things in jiffies.
>> That's what you use to compare with, and to check if it's changed since
>> last time. The only time you convert to ms is to pass it back to
>> userspace. And that's going to be a delta of jiffies always, just ensure
>> you assign last_checked = jiffies when it's setup initially.
>>
> The issue I have is that the value I am comparing to is provided by
> the code calling the ioctl so that I don't have to maintain state for
> every potential calling process in the kernel. Therefore, if we want
> the API to work with ms, I have to convert the user provided value
> back to jiffies for comparison. 
> 
> I now ran a brief test that suggests that the above condition does not
> hold and therefore the value returned in has_changed may be 1 for
> subsequent calls when the disc was not in fact changed.
> 
> Workarounds I see would be to either expose the jiffies value through
> the API (which is maybe not really clean), or making the comparison on
> the ms value (but how to deal with potential wraparounds then?). Of
> those, I would currently tend to the first and treat the nature of the
> returned timestamp as an opaque value from the user perspective - it
> is probably not really of any use to them outside of passing it back
> into the ioctl for subsequent calls. Do you see other ways to resolve
> this I may not have thought of?

Maybe it's better to just use ms internally too, and avoid the whole
conversion side of things. Hence just use ktime_get() and ktime_to_ms().

-- 
Jens Axboe