https://www.kicksecure.com/wiki/Dev/sdwdate#chrony_as_a_replacement_for_sclockadj

• An analysis of TCP secure SN generation in Linux and its privacy issues
• Tirdad kernel module for random ISN generation

An alternative proposal for editing ISNs without involving the kernel:

In T543#18086, @HulaHoop wrote:

@Patrick What is the status of integration?

@Patrick What is the status of integration? Since we have kloak this is also a great defense to have. There is a script on there for packing as a deb:

In theory, we could make sdwdate provide a local (default) (or optional opt-in server) NTP compatible time provider. Could be useful anyhow. -> sdwdate-server No idea how hard that would be.

And then configure NTP to connect only to that local NTP server.

/usr/sbin/ntpdate as far as I know doesn't accept a command line command to take an offset (or anything). It connects to remote servers in its default design.

Yes, not readily accessible from command line.

The easy way: calculating the offset between local time and the onion average in timesync then using ntpdate's slew option if the offset is less than 0.5s. Otherwise you tell it to step up the time immediately so that you are accurately mimicking the default behavior. However you can force slewing all the time with -B. This way you won't need to touch kernel syscalls as ntpdate should be able to do the operation for you.

From what I understand, this code path is only relevant when timesyncd is talking directly with NTP servers and reacting to replies about deltas between local and remote times. There is no way you can call that function from the command line when using timedatectl standalone AFAICT.

In T815#16509, @HulaHoop wrote:

It doesn't seem that timedatectl supports gradual time adjustment.

Since we are interested in ntpd's default behavior (for blending in purposes) it turns out that it performs instant clock jumps once the delta difference is excessively large otherwise its slewing algorithm would take forever to adjust the time.

It doesn't seem that timedatectl supports gradual time adjustment. Our next best option is ntpd which can do so but cannot coexist with timedatectl - we can only run either but not both. According to popcon, ntpd is the mos widely used time daemon so its the natural choice.

Currently time is set using gnu date (clock jump) (initial run after current boot) or sclockadj (consecutive run) (slow clock adjustment).

the time could be set with timedatectl by feeding it the time with this command:

sclockadj3 is done -> T686.

A miracle has happened. All of https://github.com/yongboy/bindp/pull/6 was merged by upstream.

Very well. So finally they applied our patch.

In T599#12631, @Patrick wrote:

Notified upstream. Let's see if he replies.

bindp pull request - security fixes, debian packaging, and more:
https://github.com/yongboy/bindp/pull/6

What about...?

What about...?

In T599#13705, @Patrick wrote:

Now pushed.

Now pushed.

@Patrick In the master branch the only difference in comparison to the original version that I can see is the main function at the bottom of the file. Did you not apply the changes? This code is still the previous one.

Merged into master.

Please create a new ticket for porting to some better C function.

adjtimex, as far as I can tell, is for tuning the clock to stay accurate. It's not directly for setting a new time. I assume it's used by ntp to speed up and slow down the clock, with more code that checks on it and stops it when it reaches the right time. Reimplementing this is beyond my skill.

OK. It might strain my limited C knowledge, but I'll give it shot.

Looks like at least NTP and chrony use ntp_adjtime/adjtimex

Where is adjtime being used in existing time sync applications? NTP?
chrony? systemd-timesyncd?

Using adjtime would be a simple matter (of programming), but only has microsecond precision.

A popular existing linux tool.

Do we need precise control? The only requirement (other than working) is that it imitate an existing linux tool.

adjtimex/ntp_adjtime looks quite complex, but also allow precise control on how time should be adjusted. From those two, according to manual page ntp_adjtime is preferred.

In T650#13569, @marmarek wrote:

It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.