netdev - Re: [PATCH] XFRM: MIGRATE enhancements

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: <20080911.034741.263645111.davem@davemloft.net>
Date:	Thu, 11 Sep 2008 03:47:41 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	arno@...isbad.org
Cc:	netdev@...r.kernel.org, shinta@....wide.ad.jp,
	nakam@...ux-ipv6.org, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH] XFRM: MIGRATE enhancements 

From: arno@...isbad.org (Arnaud Ebalard)
Date: Thu, 21 Aug 2008 13:10:39 +0200

> XFRM: MIGRATE enhancements (draft-ebalard-mext-pfkey-enhanced-migrate)
> 
> Provides implementation of the enhancements of XFRM/PF_KEY MIGRATE mechanism
> specified in draft-ebalard-mext-pfkey-enhanced-migrate-00. Defines associated
> PF_KEY SADB_X_EXT_KMADDRESS extension XFMR/netlink XFRMA_KMADDRESS attribute.
> 
> Signed-off-by: Arnaud Ebalard <arno@...isbad.org>

I'm mostly ok with this, but:

> @@ -1745,18 +1753,19 @@ static int xfrm_do_migrate(struct sk_buff *skb, struct nlmsghdr *nlh,
>  {
>  	struct xfrm_userpolicy_id *pi = nlmsg_data(nlh);
>  	struct xfrm_migrate m[XFRM_MAX_DEPTH];
> +	struct xfrm_kmaddress km;
>  	u8 type;
>  	int err;
>  	int n = 0;
>  
> -	if (attrs[XFRMA_MIGRATE] == NULL)
> +	if (attrs[XFRMA_MIGRATE] == NULL || attrs[XFRMA_KMADDRESS] == NULL)
>  		return -EINVAL;

This part I don't like.

This is a new restriction and will break old binaries.

Can't we cook up some kind of default kmaddress object it none is
specified by the user?  Alternatively, if we are in an environment
where the tools don't understand this facility, they won't care
what the kmaddress even is.

Generally speaking, when extending existing facilities with new
attributes, you cannot make their existence suddenly a requirement.
That breaks stuff.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html