| 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
| ||
|
Message-ID: <cc46d6ae3bba9dfcc602ac23a32fad9860cb8064.camel@redhat.com>
Date: Tue, 20 Sep 2022 12:43:53 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Andrea Mayer <andrea.mayer@...roma2.it>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
David Ahern <dsahern@...nel.org>,
Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-kselftest@...r.kernel.org,
bpf@...r.kernel.org
Cc: Stefano Salsano <stefano.salsano@...roma2.it>,
Paolo Lungaroni <paolo.lungaroni@...roma2.it>,
Ahmed Abdelsalam <ahabdels.dev@...il.com>
Subject: Re: [net-next v2 2/3] seg6: add NEXT-C-SID support for SRv6 End
behavior
On Mon, 2022-09-12 at 19:16 +0200, Andrea Mayer wrote:
> The NEXT-C-SID mechanism described in [1] offers the possibility of
> encoding several SRv6 segments within a single 128 bit SID address. Such
> a SID address is called a Compressed SID (C-SID) container. In this way,
> the length of the SID List can be drastically reduced.
>
> A SID instantiated with the NEXT-C-SID flavor considers an IPv6 address
> logically structured in three main blocks: i) Locator-Block; ii)
> Locator-Node Function; iii) Argument.
>
> C-SID container
> +------------------------------------------------------------------+
> > Locator-Block |Loc-Node| Argument |
> > |Function| |
> +------------------------------------------------------------------+
> <--------- B -----------> <- NF -> <------------- A --------------->
>
> (i) The Locator-Block can be any IPv6 prefix available to the provider;
>
> (ii) The Locator-Node Function represents the node and the function to
> be triggered when a packet is received on the node;
>
> (iii) The Argument carries the remaining C-SIDs in the current C-SID
> container.
>
> The NEXT-C-SID mechanism relies on the "flavors" framework defined in
> [2]. The flavors represent additional operations that can modify or
> extend a subset of the existing behaviors.
>
> This patch introduces the support for flavors in SRv6 End behavior
> implementing the NEXT-C-SID one. An SRv6 End behavior with NEXT-C-SID
> flavor works as an End behavior but it is capable of processing the
> compressed SID List encoded in C-SID containers.
>
> An SRv6 End behavior with NEXT-C-SID flavor can be configured to support
> user-provided Locator-Block and Locator-Node Function lengths. In this
> implementation, such lengths must be evenly divisible by 8 (i.e. must be
> byte-aligned), otherwise the kernel informs the user about invalid
> values with a meaningful error code and message through netlink_ext_ack.
>
> If Locator-Block and/or Locator-Node Function lengths are not provided
> by the user during configuration of an SRv6 End behavior instance with
> NEXT-C-SID flavor, the kernel will choose their default values i.e.,
> 32-bit Locator-Block and 16-bit Locator-Node Function.
>
> [1] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression
> [2] - https://datatracker.ietf.org/doc/html/rfc8986
>
> Signed-off-by: Andrea Mayer <andrea.mayer@...roma2.it>
> ---
> include/uapi/linux/seg6_local.h | 24 +++
> net/ipv6/seg6_local.c | 335 +++++++++++++++++++++++++++++++-
> 2 files changed, 356 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/seg6_local.h b/include/uapi/linux/seg6_local.h
> index 332b18f318f8..4fdc424c9cb3 100644
> --- a/include/uapi/linux/seg6_local.h
> +++ b/include/uapi/linux/seg6_local.h
> @@ -28,6 +28,7 @@ enum {
> SEG6_LOCAL_BPF,
> SEG6_LOCAL_VRFTABLE,
> SEG6_LOCAL_COUNTERS,
> + SEG6_LOCAL_FLAVORS,
> __SEG6_LOCAL_MAX,
> };
> #define SEG6_LOCAL_MAX (__SEG6_LOCAL_MAX - 1)
> @@ -110,4 +111,27 @@ enum {
>
> #define SEG6_LOCAL_CNT_MAX (__SEG6_LOCAL_CNT_MAX - 1)
>
> +/* SRv6 End* Flavor attributes */
> +enum {
> + SEG6_LOCAL_FLV_UNSPEC,
> + SEG6_LOCAL_FLV_OPERATION,
> + SEG6_LOCAL_FLV_LCBLOCK_BITS,
> + SEG6_LOCAL_FLV_LCNODE_FN_BITS,
> + __SEG6_LOCAL_FLV_MAX,
> +};
> +
> +#define SEG6_LOCAL_FLV_MAX (__SEG6_LOCAL_FLV_MAX - 1)
> +
> +/* Designed flavor operations for SRv6 End* Behavior */
> +enum {
> + SEG6_LOCAL_FLV_OP_UNSPEC,
> + SEG6_LOCAL_FLV_OP_PSP,
> + SEG6_LOCAL_FLV_OP_USP,
> + SEG6_LOCAL_FLV_OP_USD,
> + SEG6_LOCAL_FLV_OP_NEXT_CSID,
> + __SEG6_LOCAL_FLV_OP_MAX
> +};
> +
> +#define SEG6_LOCAL_FLV_OP_MAX (__SEG6_LOCAL_FLV_OP_MAX - 1)
> +
> #endif
> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index f43e6f0baac1..8370726ae7bf 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> @@ -73,6 +73,55 @@ struct bpf_lwt_prog {
> char *name;
> };
>
> +/* default length values (expressed in bits) for both Locator-Block and
> + * Locator-Node Function.
> + *
> + * Both SEG6_LOCAL_LCBLOCK_DBITS and SEG6_LOCAL_LCNODE_FN_DBITS *must* be:
> + * i) greater than 0;
> + * ii) evenly divisible by 8. In other terms, the lengths of the
> + * Locator-Block and Locator-Node Function must be byte-aligned (we can
> + * relax this constraint in the future if really needed).
> + *
> + * Moreover, a third condition must hold:
> + * iii) SEG6_LOCAL_LCBLOCK_DBITS + SEG6_LOCAL_LCNODE_FN_DBITS <= 128.
> + *
> + * The correctness of SEG6_LOCAL_LCBLOCK_DBITS and SEG6_LOCAL_LCNODE_FN_DBITS
> + * values are checked during the kernel compilation. If the compilation stops,
> + * check the value of these parameters to see if they meet conditions (i), (ii)
> + * and (iii).
> + */
> +#define SEG6_LOCAL_LCBLOCK_DBITS 32
> +#define SEG6_LOCAL_LCNODE_FN_DBITS 16
> +
> +/* The following next_csid_chk_{cntr,lcblock,lcblock_fn}_bits macros can be
> + * used directly to check whether the lengths (in bits) of Locator-Block and
> + * Locator-Node Function are valid according to (i), (ii), (iii).
> + */
> +#define next_csid_chk_cntr_bits(blen, flen) \
> + ((blen) + (flen) > 128)
> +
> +#define next_csid_chk_lcblock_bits(blen) \
> +({ \
> + typeof(blen) __tmp = blen; \
> + (!__tmp || __tmp > 120 || (__tmp & 0x07)); \
Just a note to mention that in theory a caller could pass a signed
argument, so the above check does not ensure that __tmp is acutally >=
8.
All the current callers use unsigned arguements, so it still looks
safe.
Cheers,
Paolo
Powered by blists - more mailing lists