netdev - Re: [net-next 1/2] seg6: add NEXT-C-SID support for SRv6 End.X behavior

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]

Date: Fri, 4 Aug 2023 14:41:18 +0200
From: Andrea Mayer <andrea.mayer@...roma2.it>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni
 <pabeni@...hat.com>, David Ahern <dsahern@...nel.org>,
        Shuah Khan
 <shuah@...nel.org>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, linux-kselftest@...r.kernel.org,
        Stefano Salsano
 <stefano.salsano@...roma2.it>,
        Paolo Lungaroni
 <paolo.lungaroni@...roma2.it>,
        Ahmed Abdelsalam <ahabdels.dev@...il.com>,
        Andrea Mayer <andrea.mayer@...roma2.it>
Subject: Re: [net-next 1/2] seg6: add NEXT-C-SID support for SRv6 End.X
 behavior

Hi Hangbin,
thanks for your time. Please see below.

On Thu, 3 Aug 2023 17:30:28 +0800
Hangbin Liu <liuhangbin@...il.com> wrote:

> On Mon, Jul 31, 2023 at 07:51:16PM +0200, Andrea Mayer wrote:
> > +/* Processing of SRv6 End, End.X, and End.T behaviors can be extended through
> > + * the flavors framework. These behaviors must report the subset of (flavor)
> > + * operations they currently implement. In this way, if a user specifies a
> > + * flavor combination that is not supported by a given End* behavior, the
> > + * kernel refuses to instantiate the tunnel reporting the error.
> > + */
> > +static int seg6_flv_supp_ops_by_action(int action, __u32 *fops)
> > +{
> > +	switch (action) {
> > +	case SEG6_LOCAL_ACTION_END:
> > +		*fops = SEG6_LOCAL_END_FLV_SUPP_OPS;
> > +		break;
> > +	case SEG6_LOCAL_ACTION_END_X:
> > +		*fops = SEG6_LOCAL_END_X_FLV_SUPP_OPS;
> > +		break;
> > +	default:
> > +		return -EOPNOTSUPP;
> > +	}
> > +
> > +	return 0;
> >  }
> >  
> 
> ...
> 
> > @@ -2070,7 +2131,8 @@ static int parse_nla_flavors(struct nlattr **attrs, struct seg6_local_lwt *slwt,
> >  {
> >  	struct seg6_flavors_info *finfo = &slwt->flv_info;
> >  	struct nlattr *tb[SEG6_LOCAL_FLV_MAX + 1];
> > -	unsigned long fops;
> > +	int action = slwt->action;
> > +	__u32 fops, supp_fops = 0;
> >  	int rc;
> >  
> >  	rc = nla_parse_nested_deprecated(tb, SEG6_LOCAL_FLV_MAX,
> > @@ -2086,7 +2148,8 @@ static int parse_nla_flavors(struct nlattr **attrs, struct seg6_local_lwt *slwt,
> >  		return -EINVAL;
> >  
> >  	fops = nla_get_u32(tb[SEG6_LOCAL_FLV_OPERATION]);
> > -	if (fops & ~SEG6_LOCAL_FLV_SUPP_OPS) {
> > +	rc = seg6_flv_supp_ops_by_action(action, &supp_fops);
> > +	if (rc < 0 || !supp_fops || (fops & ~supp_fops)) {
> 
> if rc == 0, the supp_fops won't be 0.
> 

Yes, you're right.

In this patch, supp_fops is always set properly when rc == 0.
Since seg6_flv_supp_ops_by_action() should be extended in the event that other
behaviors receive flavors support, I added this check in case the "supp_fops"
field was set incorrectly or not set at all.
Note that supp_fops == 0 must be considered an inadmissible value.


So, I think we have two possibilities:
  i) remove this "defensive" check, assuming that supp_fops will always be set
     correctly by seg6_flv_supp_ops_by_action() (when rc == 0, like in this
     patch); 
 ii) improve the check by explicitly indicating with a pr_warn_once, for
     example, the condition that is occurring is unexpected.

for (ii), something like this:

parse_nla_flavors(...)
{
    [...]
    supp_fops = 0;
    [...]

    rc = seg6_flv_supp_ops_by_action(action, &supp_fops);
    if (!rc && !supp_fops) {
   	 /* supported flavors mask cannot be zero as it is considered to
   	  * be invalid.
   	  */
   	 pr_warn_once("seg6local: invalid Flavor operation(s)");
   	 return -EINVAL;
    }

    fops = nla_get_u32(tb[SEG6_LOCAL_FLV_OPERATION]);
    if (rc < 0 || (fops & ~supp_fops)) {
   	 NL_SET_ERR_MSG(extack, "Unsupported Flavor operation(s)");
   	 return -EOPNOTSUPP;
    }

    finfo->flv_ops = fops;

    [...]
}

parse_nla_flavors() is called in the control path so another check would not
hit performance. I am more inclined to consider solution (ii).

What do you think?

> Thanks
> Hangbin

Ciao,
Andrea