netdev - Re: [PATCH net-next v4 2/5] ipv6: ioam: Data plane support for Pre-allocated Trace

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]

Message-ID: <20210531212052.14aca857@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Mon, 31 May 2021 21:20:52 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Justin Iurman <justin.iurman@...ege.be>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, tom@...bertland.com
Subject: Re: [PATCH net-next v4 2/5] ipv6: ioam: Data plane support for
 Pre-allocated Trace

On Mon, 31 May 2021 13:50:44 +0200 (CEST) Justin Iurman wrote:
> >> Actually, it's more than for semantic reasons. Take the following topology:
> >> 
> >>  _____              _____              _____
> >> |     | eth0  eth0 |     | eth1  eth0 |     |
> >> |  A  |.----------.|  B  |.----------.|  C  |
> >> |_____|            |_____|            |_____|
> >> 
> >> If I only want IOAM to be deployed from A to C but not from C to A,
> >> then I would need the following on B (let's just focus on B):
> >> 
> >> B.eth0.ioam6_enabled = 1 // enable IOAM *on input* for B.eth0
> >> B.eth0.ioam6_id = B1
> >> B.eth1.ioam6_id = B2
> >> 
> >> Back to your suggestion, if I only had one field (i.e., ioam6_id != 0
> >> to enable IOAM), I would end up with:
> >> 
> >> B.eth0.ioam6_id = B1 // (!= 0)
> >> B.eth1.ioam6_id = B2 // (!= 0)
> >> 
> >> Which means in this case that IOAM would also be enabled on B for the
> >> reverse path. So we definitely need two fields to distinguish both
> >> the status (enabled/disabled) and the IOAM ID of an interface.  
> > 
> > Makes sense. Is it okay to assume 0 is equivalent to ~0, though:
> > 
> > +		raw32 = dev_net(skb->dev)->ipv6.sysctl.ioam6_id;
> > +		if (!raw32)
> > +			raw32 = IOAM6_EMPTY_u24;
> > 
> > etc. Quick grep through the RFC only reveals that ~0 is special (not
> > available). Should we init ids to ~0 instead of 0 explicitly?  
> 
> Yes, I think so. And it is indeed correct to assume that. So, if it's
> fine for you to init IDs to ~0, then it'd be definitely a big yes
> from me.

Yes, we can init the sysctl to ~0, I don't see why not.