netdev - Re: [PATCH net-next 2/2] include/uapi/linux/xfrm.h: Pack struct xfrm_usersa

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: <1389213183.1644.31.camel@bwh-desktop.uk.level5networks.com>
Date:	Wed, 8 Jan 2014 20:33:03 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Fan Du <fan.du@...driver.com>
CC:	<steffen.klassert@...unet.com>, <davem@...emloft.net>,
	<stephen@...workplumber.org>, <dev@...ts.strongswan.org>,
	<netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/2] include/uapi/linux/xfrm.h: Pack struct
 xfrm_usersa_info

On Tue, 2014-01-07 at 14:48 +0800, Fan Du wrote:
> Otherwise 64bits kernel has sizeof(struct xfrm_usersa_info) 224 bytes,
> while 32bits compiled iproute2 see the same structure as 220 bytes, which
> leading deficit xfrm sa, in turn broken IPsec connectivity.
>
> Fix this by packing the structure.
> 
> Signed-off-by: Fan Du <fan.du@...driver.com>
> ---
>  include/uapi/linux/xfrm.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
> index 470bfae..61460c4 100644
> --- a/include/uapi/linux/xfrm.h
> +++ b/include/uapi/linux/xfrm.h
> @@ -366,7 +366,7 @@ struct xfrm_usersa_info {
>  #define XFRM_STATE_AF_UNSPEC	32
>  #define XFRM_STATE_ALIGN4	64
>  #define XFRM_STATE_ESN		128
> -};
> +} __attribute__((packed));
>  
>  #define XFRM_SA_XFLAG_DONT_ENCAP_DSCP	1
>  

That change will make access to the structure very slow on some
architectures, and I suspect it will cause other compatibility problems.

I think the right thing to do is to reduce the minimum length of the
structure in the netlink policy so that padding at the end is not
required.  (It looks like all field offsets will be the same on all
32/64-bit architecture pairs and there is only a differing amount of
padding at the end of the structure for 32/64-bit alignment.)

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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