On Wed, Nov 13, 2024 at 02:14:12AM +0100, Stefano Brivio wrote:

Nits only:

On Tue, 12 Nov 2024 15:06:15 +1100 David Gibson wrote:

...

Currently the large ndp() function responds to all NDP messages we handle, both parsing the message as necessary and sending the response. Split out the code to construct and send specific message types into ndp_na() (to send NA messages) and ndp_ra() (to send RA messages).

As well as breaking up an excessively large function, this is a first step to being able to send unsolicited NDP messages.

While we're there, remove a slighty ugly goto.

Signed-off-by: David Gibson --- ndp.c | 136 +++++++++++++++++++++++++++++++++------------------------- 1 file changed, 78 insertions(+), 58 deletions(-)

diff --git a/ndp.c b/ndp.c index fa1b67a..e876c34 100644 --- a/ndp.c +++ b/ndp.c @@ -186,16 +186,13 @@ static void ndp_send(const struct ctx *c, const struct in6_addr *dst, }

/** - * ndp() - Check for NDP solicitations, reply as needed + * ndp_na() - Send an NDP Neighbour Advertisement (NA) message * @c: Execution context - * @ih: ICMPv6 header - * @saddr: Source IPv6 address - * @p: Packet pool - * - * Return: 0 if not handled here, 1 if handled, -1 on failure + * @dst: IPv6 address to send the NA to + * @addr: IPv6 address to advertise */ -int ndp(const struct ctx *c, const struct icmp6hdr *ih, - const struct in6_addr *saddr, const struct pool *p) +static void ndp_na(const struct ctx *c, const struct in6_addr *dst, + const void *addr) { struct ndp_na na = { .ih = { @@ -212,6 +209,20 @@ int ndp(const struct ctx *c, const struct icmp6hdr *ih, }, } }; + + memcpy(&na.target_addr, addr, sizeof(na.target_addr)); + memcpy(na.target_l2_addr.mac, c->our_tap_mac, ETH_ALEN); + + ndp_send(c, dst, &na, sizeof(na)); +} + +/** + * ndp_ra() - Send an NDP Router Advertisement (RA) message + * @c: Execution context + * @dst: IPv6 address to send the RA to + */ +static void ndp_ra(const struct ctx *c, const struct in6_addr *dst) +{ struct ndp_ra ra = { .ih = { .icmp6_type = RA, @@ -238,58 +249,28 @@ int ndp(const struct ctx *c, const struct icmp6hdr *ih, }, }, }; + unsigned char *ptr = NULL;

- if (ih->icmp6_type < RS || ih->icmp6_type > NA) - return 0; - - if (c->no_ndp) - return 1; - - if (ih->icmp6_type == NS) { - const struct ndp_ns *ns = - packet_get(p, 0, 0, sizeof(struct ndp_ns), NULL); + memcpy(&ra.prefix, &c->ip6.addr, sizeof(ra.prefix));

- if (!ns) - return -1; + ptr = &ra.var[0];

- if (IN6_IS_ADDR_UNSPECIFIED(saddr)) - return 1; - - info("NDP: received NS, sending NA"); - - memcpy(&na.target_addr, &ns->target_addr, - sizeof(na.target_addr)); - memcpy(na.target_l2_addr.mac, c->our_tap_mac, ETH_ALEN); + if (c->mtu != -1) { + struct opt_mtu *mtu = (struct opt_mtu *)ptr; + *mtu = (struct opt_mtu) { + .header = { + .type = OPT_MTU, + .len = 1, + }, + .value = htonl(c->mtu), + }; + ptr += sizeof(struct opt_mtu); + }

- ndp_send(c, saddr, &na, sizeof(struct ndp_na)); - } else if (ih->icmp6_type == RS) { - unsigned char *ptr = NULL; + if (!c->no_dhcp_dns) { size_t dns_s_len = 0; int i, n;

- if (c->no_ra) - return 1; - - info("NDP: received RS, sending RA"); - memcpy(&ra.prefix, &c->ip6.addr, sizeof(ra.prefix)); - - ptr = &ra.var[0]; - - if (c->mtu != -1) { - struct opt_mtu *mtu = (struct opt_mtu *)ptr; - *mtu = (struct opt_mtu) { - .header = { - .type = OPT_MTU, - .len = 1, - }, - .value = htonl(c->mtu), - }; - ptr += sizeof(struct opt_mtu); - } - - if (c->no_dhcp_dns) - goto dns_done; - for (n = 0; !IN6_IS_ADDR_UNSPECIFIED(&c->ip6.dns[n]); n++); if (n) { struct opt_rdnss *rdnss = (struct opt_rdnss *)ptr; @@ -305,7 +286,7 @@ int ndp(const struct ctx *c, const struct icmp6hdr *ih, sizeof(rdnss->dns[i])); } ptr += offsetof(struct opt_rdnss, dns) + - i * sizeof(rdnss->dns[0]); + i * sizeof(rdnss->dns[0]);

Unrelated change, less readable, probably from your new editor / clangd?

Curiously, no, I wasn't using Zed at the time. That just happened because I reindented the block a couple of times, and apparently my emacs indent settings aren't *quite* the same as passt standard. Anyway, fixed.

...

for (n = 0; *c->dns_search[n].n; n++) dns_s_len += strlen(c->dns_search[n].n) + 2; @@ -329,7 +310,7 @@ int ndp(const struct ctx *c, const struct icmp6hdr *ih, *(ptr++) = '.';

len = sizeof(dnssl->domains) - - (ptr - dnssl->domains); + (ptr - dnssl->domains);

Same here.

...

strncpy((char *)ptr, c->dns_search[i].n, len); for (dot = (char *)ptr - 1; *dot; dot++) { @@ -343,11 +324,50 @@ int ndp(const struct ctx *c, const struct icmp6hdr *ih, memset(ptr, 0, 8 - dns_s_len % 8); /* padding */ ptr += 8 - dns_s_len % 8; } + }

-dns_done: - memcpy(&ra.source_ll.mac, c->our_tap_mac, ETH_ALEN); + memcpy(&ra.source_ll.mac, c->our_tap_mac, ETH_ALEN);

- ndp_send(c, saddr, &ra, ptr - (unsigned char *)&ra); + ndp_send(c, dst, &ra, ptr - (unsigned char *)&ra); +} + +/** + * ndp() - Check for NDP solicitations, reply as needed + * @c: Execution context + * @ih: ICMPv6 header + * @saddr: Source IPv6 address + * @p: Packet pool + * + * Return: 0 if not handled here, 1 if handled, -1 on failure + */ +int ndp(const struct ctx *c, const struct icmp6hdr *ih, + const struct in6_addr *saddr, const struct pool *p) +{ + if (ih->icmp6_type < RS || ih->icmp6_type > NA) + return 0; + + if (c->no_ndp) + return 1; + + if (ih->icmp6_type == NS) { + const struct ndp_ns *ns = + packet_get(p, 0, 0, sizeof(struct ndp_ns), NULL);

The assignment could go on its line here? We don't save any line this way.

Good point, done.

...

+ + if (!ns) + return -1; + + if (IN6_IS_ADDR_UNSPECIFIED(saddr)) + return 1; + + info("NDP: received NS, sending NA"); + + ndp_na(c, saddr, &ns->target_addr); + } else if (ih->icmp6_type == RS) { + if (c->no_ra) + return 1; + + info("NDP: received RS, sending RA"); + ndp_ra(c, saddr); }

return 1;

-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson

Kind of nits only, the whole series looks good to me otherwise: On Tue, 12 Nov 2024 15:06:18 +1100 David Gibson wrote:

Currently, our NDP implementation only sends Router Advertisements (RA) when it receives a Router Solicitation (RS) from the guest. However, RFC 4861 requires that we periodically send unsolicited RAs.

Linux as a guest also requires this: it will send an RS when a link first comes up, but the route it gets from this will have a finite lifetime (we set this to 65535s, the maximum allowed, around 18 hours). When that expires the guest will not send a new RS, but instead expects the route to have been renewed (if still valid) by an unsolicited RA.

Implement sending unsolicited RAs on a partially randomised timer, as required by RFC 4861. The RFC also specifies that solicited RAs should also be delayed, or even not omitted, if the next unsolicited RA is soon

s/not//

enough. For now we don't do that, always sending an immediate RA in response to an RS. We can get away with this because in our use cases we expect to just have passt itself and the guest on the link, rather than a large broadcast domain.

Link: https://github.com/kubevirt/kubevirt/issues/13191 Signed-off-by: David Gibson --- ip.h | 9 +++++++++ ndp.c | 41 +++++++++++++++++++++++++++++++++++++++++ ndp.h | 3 +++ passt.c | 3 +++ 4 files changed, 56 insertions(+)

diff --git a/ip.h b/ip.h index b8d4a5b..0742612 100644 --- a/ip.h +++ b/ip.h @@ -92,4 +92,13 @@ struct ipv6_opt_hdr {

char *ipv6_l4hdr(const struct pool *p, int idx, size_t offset, uint8_t *proto, size_t *dlen); + +/* IPv6 link-local all-nodes multicast adddress, ff02::1 */ +static const struct in6_addr in6addr_ll_all_nodes = { + .s6_addr = { + 0xff, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, + }, +}; + #endif /* IP_H */ diff --git a/ndp.c b/ndp.c index c5fbccf..8c019df 100644 --- a/ndp.c +++ b/ndp.c @@ -372,3 +372,44 @@ int ndp(const struct ctx *c, const struct icmp6hdr *ih,

return 1; } + +/* Default interval between unsolicited RAs (seconds) */ +#define DEFAULT_MAX_RTR_ADV_INTERVAL 600 /* RFC 4861, 6.2.1 */ + +/* Minimum required interval between RAs (seconds) */ +#define MIN_DELAY_BETWEEN_RAS 3 /* RFC 4861, 10 */

By the way, I think this is still all correct, as I quickly double checked it against RFC 8319. If you're not aware: see also sections 3 and 4 there.

+ +static time_t next_ra; + +/** + * ndp_timer() - Send unsolicited NDP messages if necessary + * @c: Execution context + * @now: Current (monotonic) time + */ +void ndp_timer(const struct ctx *c, const struct timespec *now) +{ + time_t max_rtr_adv_interval = DEFAULT_MAX_RTR_ADV_INTERVAL; + time_t min_rtr_adv_interval, interval; + + if (c->no_ra || now->tv_sec < next_ra) + return; + + /* We must advertise before the route's lifetime expires */ + max_rtr_adv_interval = MIN(max_rtr_adv_interval, RT_LIFETIME - 1); + + /* But we must not go smaller than the minimum delay */ + max_rtr_adv_interval = MAX(max_rtr_adv_interval, MIN_DELAY_BETWEEN_RAS); + + /* RFC 4861, 6.2.1 */ + min_rtr_adv_interval = MAX(max_rtr_adv_interval / 3, + MIN_DELAY_BETWEEN_RAS); + + interval = min_rtr_adv_interval + + random() % (max_rtr_adv_interval - min_rtr_adv_interval);

So, I would have called srandom() before this, especially in the case we get, one day, two instances of passt advertising at the same time. But Coverity is more annoying than I am and reports: /home/sbrivio/passt/ndp.c:408:3: Type: Calling risky function (DC.WEAK_CRYPTO) /home/sbrivio/passt/ndp.c:408:3: dont_call: "random" should not be used for security-related applications, because linear congruential algorithms are too easy to break. /home/sbrivio/passt/ndp.c:408:3: remediation: Use a compliant random number generator, such as "/dev/random" or "/dev/urandom" on Unix-like systems, and CNG (Cryptography API: Next Generation) on Windows. Of course it's all bogus but I would have a *slight* preference to get rid of this, by either picking a fixed interval deviation at the beginning with getrandom(), or using something like tcp_init_seq() modulo something << 600. Alternatively, we could also keep /dev/random or /dev/urandom open but it looks totally overkill. At that point I'd rather keep random() here.

+ + info("NDP: sending unsolicited RA, next in %llds", (long long)interval); + + ndp_ra(c, &in6addr_ll_all_nodes); + + next_ra = now->tv_sec + interval; +} diff --git a/ndp.h b/ndp.h index abe6d02..41c2000 100644 --- a/ndp.h +++ b/ndp.h @@ -6,7 +6,10 @@ #ifndef NDP_H #define NDP_H

+struct icmp6hdr; + int ndp(const struct ctx *c, const struct icmp6hdr *ih, const struct in6_addr *saddr, const struct pool *p); +void ndp_timer(const struct ctx *c, const struct timespec *now);

#endif /* NDP_H */ diff --git a/passt.c b/passt.c index fac6101..454ac8e 100644 --- a/passt.c +++ b/passt.c @@ -52,6 +52,7 @@ #include "arch.h" #include "log.h" #include "tcp_splice.h" +#include "ndp.h"

#define EPOLL_EVENTS 8

@@ -110,6 +111,8 @@ static void post_handler(struct ctx *c, const struct timespec *now)

flow_defer_handler(c, now); #undef CALL_PROTO_HANDLER + + ndp_timer(c, now); }

/**

-- Stefano

On Wed, 13 Nov 2024 14:01:16 +1100 David Gibson wrote:

On Wed, Nov 13, 2024 at 02:14:16AM +0100, Stefano Brivio wrote:

...

Kind of nits only, the whole series looks good to me otherwise:

On Tue, 12 Nov 2024 15:06:18 +1100 David Gibson wrote:

...

Currently, our NDP implementation only sends Router Advertisements (RA) when it receives a Router Solicitation (RS) from the guest. However, RFC 4861 requires that we periodically send unsolicited RAs.

Linux as a guest also requires this: it will send an RS when a link first comes up, but the route it gets from this will have a finite lifetime (we set this to 65535s, the maximum allowed, around 18 hours). When that expires the guest will not send a new RS, but instead expects the route to have been renewed (if still valid) by an unsolicited RA.

Implement sending unsolicited RAs on a partially randomised timer, as required by RFC 4861. The RFC also specifies that solicited RAs should also be delayed, or even not omitted, if the next unsolicited RA is soon

s/not//

Fixed.

...

...

enough. For now we don't do that, always sending an immediate RA in response to an RS. We can get away with this because in our use cases we expect to just have passt itself and the guest on the link, rather than a large broadcast domain.

Link: https://github.com/kubevirt/kubevirt/issues/13191 Signed-off-by: David Gibson --- ip.h | 9 +++++++++ ndp.c | 41 +++++++++++++++++++++++++++++++++++++++++ ndp.h | 3 +++ passt.c | 3 +++ 4 files changed, 56 insertions(+)

diff --git a/ip.h b/ip.h index b8d4a5b..0742612 100644 --- a/ip.h +++ b/ip.h @@ -92,4 +92,13 @@ struct ipv6_opt_hdr {

char *ipv6_l4hdr(const struct pool *p, int idx, size_t offset, uint8_t *proto, size_t *dlen); + +/* IPv6 link-local all-nodes multicast adddress, ff02::1 */ +static const struct in6_addr in6addr_ll_all_nodes = { + .s6_addr = { + 0xff, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, + }, +}; + #endif /* IP_H */ diff --git a/ndp.c b/ndp.c index c5fbccf..8c019df 100644 --- a/ndp.c +++ b/ndp.c @@ -372,3 +372,44 @@ int ndp(const struct ctx *c, const struct icmp6hdr *ih,

return 1; } + +/* Default interval between unsolicited RAs (seconds) */ +#define DEFAULT_MAX_RTR_ADV_INTERVAL 600 /* RFC 4861, 6.2.1 */ + +/* Minimum required interval between RAs (seconds) */ +#define MIN_DELAY_BETWEEN_RAS 3 /* RFC 4861, 10 */

By the way, I think this is still all correct, as I quickly double checked it against RFC 8319. If you're not aware: see also sections 3 and 4 there.

Ah, thanks for checking. I didn't think to look for a superseding RFC.

...

...

+ +static time_t next_ra; + +/** + * ndp_timer() - Send unsolicited NDP messages if necessary + * @c: Execution context + * @now: Current (monotonic) time + */ +void ndp_timer(const struct ctx *c, const struct timespec *now) +{ + time_t max_rtr_adv_interval = DEFAULT_MAX_RTR_ADV_INTERVAL; + time_t min_rtr_adv_interval, interval; + + if (c->no_ra || now->tv_sec < next_ra) + return; + + /* We must advertise before the route's lifetime expires */ + max_rtr_adv_interval = MIN(max_rtr_adv_interval, RT_LIFETIME - 1); + + /* But we must not go smaller than the minimum delay */ + max_rtr_adv_interval = MAX(max_rtr_adv_interval, MIN_DELAY_BETWEEN_RAS); + + /* RFC 4861, 6.2.1 */ + min_rtr_adv_interval = MAX(max_rtr_adv_interval / 3, + MIN_DELAY_BETWEEN_RAS); + + interval = min_rtr_adv_interval + + random() % (max_rtr_adv_interval - min_rtr_adv_interval);

So, I would have called srandom() before this, especially in the case we get, one day, two instances of passt advertising at the same time.

Good point, I'll add that.

...

But Coverity is more annoying than I am and reports:

/home/sbrivio/passt/ndp.c:408:3: Type: Calling risky function (DC.WEAK_CRYPTO)

/home/sbrivio/passt/ndp.c:408:3: dont_call: "random" should not be used for security-related applications, because linear congruential algorithms are too easy to break. /home/sbrivio/passt/ndp.c:408:3: remediation: Use a compliant random number generator, such as "/dev/random" or "/dev/urandom" on Unix-like systems, and CNG (Cryptography API: Next Generation) on Windows.

Of course it's all bogus but I would have a *slight* preference to get rid of this, by either picking a fixed interval deviation at the beginning with getrandom(), or using something like tcp_init_seq() modulo something << 600.

I don't think the latter approach really works. Using the time as the basic input means its still subject to two passt instances (say) starting at the same time on the same link picking the same values and keeping on sending their announcements in lockstep.

Well, but the seeds would be different (I would still factor hash_secret in), so we would start out of sync right away, and we would use a fine-grained time resolution to pick a coarser one, which adds (enough) to the pseudorandomness.

Picking a random interval once is better. Still, I don't particularly like deviating from the RFC's recommendations just to keep a fussy tool happy.

Oh, I thought it would still fit the recommendation, but now I read RFC 4861 6.2.4 again and it definitely doesn't.

...

Alternatively, we could also keep /dev/random or /dev/urandom open but it looks totally overkill. At that point I'd rather keep random() here.

Also a waste of /dev/random entropy, IMO.

Surely there must be some way we can suppress the Coverity whinge.

That adds more maintenance burden than having a warning at this point, so I'd rather not try to suppress anything. If the tcp_init_seq()-like thing works, I'd be happy, otherwise let's leave this like it is. -- Stefano