Dear Genodians
We are looking into using wireguard to access sensor nodes connected by a genode-powered gateway through a wireguard server running on Linux. By trying this, we discovered that the wireguard connection works only once, and upon restart of the runscript yields "Invalid handshake initiation" in the servers log.
We based on a post by wireguard developer Jason Donenfeld [1] (key phrase: "WireGuard relies on a timestamp counter always moving forward.") we concluded that this problem is caused by DDE restarting at time zero instead of using an RTC connection, thereby triggering wireguard's replay protection mechanism on the server peer.
We're not sure how to best fix the problem. Do you have any suggestions?
[1] https://inbox.vuxu.org/wireguard/7aa9fe5e-2ae2-cf8b-ae6d-d98de2031b44@posteo...
Best Regards
Stefan Thöni
gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com
Hello Stefan,
As far as I can tell, you are right. DDE Linux has no initial time and this very likely should cause what you observe because of the replay protection.
A quick trace back through the Linux code:
Wireguard uses ktime_get_real_ts64 [1] for its TAI64 which uses xtime_sec as base which is set by tk_set_xtime [2] which leads to do_settimeofday64 [3], and rtc_hctosys [4], and __devm_rtc_register_device/devm_rtc_device_register [5] which should be called by the local RTC driver [6].
A good way to solve your problem would be creating a new pseudo RTC driver for Linux by using a preferably simple one from the list of the existing drivers as blueprint. This driver would call the register function on probe like in [7]. Apart from that, the driver would set only the read function (the function needed in rtc_hctosys) in its rtc_ops array [8] and implement this function via Genodes RTC service provided by a Genode RTC driver.
The next step would be integrating this driver into your Linux. You can do so by adding the RTC subsystem files as well and then simply disguising as a driver that already exists. DDE Linux uses a pre-generated list of init calls of components of a real Linux, and therefore if your driver carries the right hooks (module_platform_driver_probe macro, platform_driver struct) of an existing driver [9] it should work without further ado. I would recommend you disguise as a very unspecific driver like rtc-generic in the example.
Cheers, Martin
[1] https://elixir.bootlin.com/linux/latest/source/kernel/time/timekeeping.c#L81...
[2] https://elixir.bootlin.com/linux/latest/source/kernel/time/timekeeping.c#L12...
[3] https://elixir.bootlin.com/linux/latest/source/kernel/time/timekeeping.c#L13...
[4] https://elixir.bootlin.com/linux/latest/source/drivers/rtc/class.c#L83
[5] https://elixir.bootlin.com/linux/latest/source/drivers/rtc/class.c#L468
[6] https://elixir.bootlin.com/linux/latest/C/ident/devm_rtc_device_register
[7] https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-as3722.c#L192
[8] https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-as3722.c#L160
[9] https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-generic.c#L34
On 09.05.23 14:48, Stefan Thöni wrote:
Dear Genodians
We are looking into using wireguard to access sensor nodes connected by a genode-powered gateway through a wireguard server running on Linux. By trying this, we discovered that the wireguard connection works only once, and upon restart of the runscript yields "Invalid handshake initiation" in the servers log.
We based on a post by wireguard developer Jason Donenfeld [1] (key phrase: "WireGuard relies on a timestamp counter always moving forward.") we concluded that this problem is caused by DDE restarting at time zero instead of using an RTC connection, thereby triggering wireguard's replay protection mechanism on the server peer.
We're not sure how to best fix the problem. Do you have any suggestions?
[1] https://inbox.vuxu.org/wireguard/7aa9fe5e-2ae2-cf8b-ae6d-d98de2031b44@posteo...
Best Regards
Stefan Thöni
gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Martin
We have managed to provide RTC to wireguard and the handshake with a remote peer now works reliably when it's initiated.
But we have discovered another problem in that the timers do not fire at all for wireguard, thereby preventing retransmission of lost handshakes. This prevents our scenario from with DHCP from working as the IP address isn't yet configured when wireguard first tries to connect.
We have traced the setup of the timers and found no obvious reason for them not to work. The problem seems to exist independent of our RTC fix.
Do you have any ideas why the timers wouldn't be working for wireguard?
Cheers Stefan
Hello Stefan,
This is strange as the new run/driver_time test, AFAIK, tests exactly this and on the same emulation environment as Wireguard. We would need to have more information on your issue. First of all, are you sure that this issue exists independent from any of your local modifications (i.e. on genodelabs/master)? And if yes, what setup do you use (run script)?
Cheers, Martin
On 29.05.23 10:07, Stefan Thöni wrote:
Hello Martin
We have managed to provide RTC to wireguard and the handshake with a remote peer now works reliably when it's initiated.
But we have discovered another problem in that the timers do not fire at all for wireguard, thereby preventing retransmission of lost handshakes. This prevents our scenario from with DHCP from working as the IP address isn't yet configured when wireguard first tries to connect.
We have traced the setup of the timers and found no obvious reason for them not to work. The problem seems to exist independent of our RTC fix.
Do you have any ideas why the timers wouldn't be working for wireguard?
Cheers Stefan
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
Martin Stein -
Stefan Thöni