* why not use ktime_get_clocktai_ts64
@ 2022-06-16 1:48 Jacob Lifshay
2022-06-17 11:56 ` Jason A. Donenfeld
0 siblings, 1 reply; 3+ messages in thread
From: Jacob Lifshay @ 2022-06-16 1:48 UTC (permalink / raw)
To: wireguard
I was reading in noise.c and noticed you use ktime_get_real_ts64 and
do manual adjustments (the current code is broken if/when there's
another leap second) rather than using ktime_get_clocktai_ts64 which
already handles compensation for leap seconds.
https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/noise.c?id=7fae4596a269d2f9a6a7d1a8695c3a68ab34f7be#n501
Is there a reason for that?
Jacob
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: why not use ktime_get_clocktai_ts64
2022-06-16 1:48 why not use ktime_get_clocktai_ts64 Jacob Lifshay
@ 2022-06-17 11:56 ` Jason A. Donenfeld
2022-06-19 6:16 ` Jacob Lifshay
0 siblings, 1 reply; 3+ messages in thread
From: Jason A. Donenfeld @ 2022-06-17 11:56 UTC (permalink / raw)
To: Jacob Lifshay; +Cc: wireguard
Hi Jacob,
On Wed, Jun 15, 2022 at 06:48:08PM -0700, Jacob Lifshay wrote:
> I was reading in noise.c and noticed you use ktime_get_real_ts64 and
> do manual adjustments (the current code is broken if/when there's
> another leap second) rather than using ktime_get_clocktai_ts64 which
> already handles compensation for leap seconds.
>
> https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/noise.c?id=7fae4596a269d2f9a6a7d1a8695c3a68ab34f7be#n501
>
> Is there a reason for that?
Not really I guess. The only requirement, though, is that the timestamps
are monotonic with respect to the particular localprivate-remotepublic
pairing of peers. So I'm not sure it matters?
Jason
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: why not use ktime_get_clocktai_ts64
2022-06-17 11:56 ` Jason A. Donenfeld
@ 2022-06-19 6:16 ` Jacob Lifshay
0 siblings, 0 replies; 3+ messages in thread
From: Jacob Lifshay @ 2022-06-19 6:16 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: wireguard
On Fri, Jun 17, 2022, 04:56 Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi Jacob,
>
> On Wed, Jun 15, 2022 at 06:48:08PM -0700, Jacob Lifshay wrote:
> > I was reading in noise.c and noticed you use ktime_get_real_ts64 and
> > do manual adjustments (the current code is broken if/when there's
> > another leap second) rather than using ktime_get_clocktai_ts64 which
> > already handles compensation for leap seconds.
> >
> > https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/noise.c?id=7fae4596a269d2f9a6a7d1a8695c3a68ab34f7be#n501
> >
> > Is there a reason for that?
>
> Not really I guess. The only requirement, though, is that the timestamps
> are monotonic with respect to the particular localprivate-remotepublic
> pairing of peers. So I'm not sure it matters?
ok. Apparently linux's TAI clock offset is often not set on linux
systems, so that's a good reason not to use it.
Do note that 10s is the wrong offset, the correct value is 37s iirc.
see also (related issue on tai64 crate -- also uses the wrong offset):
https://github.com/RustCrypto/formats/issues/675
Jacob
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-06-19 6:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-16 1:48 why not use ktime_get_clocktai_ts64 Jacob Lifshay
2022-06-17 11:56 ` Jason A. Donenfeld
2022-06-19 6:16 ` Jacob Lifshay
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).