netdev - Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

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]

Date: Thu, 27 Jun 2024 15:50:01 +0200
From: Peter Hilber <peter.hilber@...nsynergy.com>
To: David Woodhouse <dwmw2@...radead.org>, linux-kernel@...r.kernel.org,
 virtualization@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 linux-rtc@...r.kernel.org, "Ridoux, Julien" <ridouxj@...zon.com>,
 virtio-dev@...ts.linux.dev
Cc: "Christopher S. Hall" <christopher.s.hall@...el.com>,
 Jason Wang <jasowang@...hat.com>, John Stultz <jstultz@...gle.com>,
 "Michael S. Tsirkin" <mst@...hat.com>, netdev@...r.kernel.org,
 Richard Cochran <richardcochran@...il.com>, Stephen Boyd <sboyd@...nel.org>,
 Thomas Gleixner <tglx@...utronix.de>, Xuan Zhuo
 <xuanzhuo@...ux.alibaba.com>, Marc Zyngier <maz@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Daniel Lezcano <daniel.lezcano@...aro.org>,
 Alessandro Zummo <a.zummo@...ertech.it>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>
Subject: Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

On 21.06.24 10:45, David Woodhouse wrote:
> On Thu, 2024-06-20 at 17:19 +0100, David Woodhouse wrote:
>>
>>>
>>>> +
>>>> +       /* Counter frequency, and error margin. Units of (second >> 64) */
>>>> +       uint64_t counter_period_frac_sec;
>>>
>>> AFAIU this might limit the precision in case of high counter frequencies.
>>> Could the unit be aligned to the expected frequency band of counters?
>>
>> This field indicates the period of a single tick, in units of 1>>64 of
>> a second. That's about 5.4e-20 seconds, or 54 zeptoseconds? 
>>
>> Can you walk me through a calculation where you believe that level of
>> precision is insufficient?
>>
>> I guess the precision matters if the structure isn't updated for a long
>> period of time, and the delta between the current counter and the
>> snapshot is high? That's a *lot* of 54 zeptosecondses? But you really
>> would need a *lot* of them before you care? And if nobody's been
>> calibrating your counter for that long, surely you have bigger worries?
>>
>> Am I missing something there?
> 
> Hm, that was a bit rushed at the end of the day; let's take a better look...
> 
> Let's take a hypothetical example of a 100GHz counter. That's two
> orders of magnitude more than today's Arm arch counter.
> 
> The period of such a counter would be 10 picoseconds. 
> 
> (Let's ignore the question of how far light actually travels in that
> time and how *realistic* that example is, for the moment.)
> 
> It turns out that at that rate, there *are* a lot of 54 zeptosecondses
> of precision loss in the day. It could be half a millisecond a day, or
> 20µs an hour.
> 
> That particular example of 10 picoseconds is 184467440.7370955
> (seconds>>64) which could be truncated to 184467440 — losing about 4PPB
> (a third of a millisecond a day; 14µs an hour).
> 
> So yeah, I suppose a 'shift' field could make sense. It's easy enough
> to consume on the guest side as it doesn't really perturb the 128-bit
> multiplication very much; especially if we don't let it be negative.
> 
> And implementations *can* just set it to zero. It hurts nobody.
> 
> Or were you thinking of just using a fixed shift like (seconds>>80)
> instead?

The 'shift' field should be fine.