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: <52CE5CBA.9000200@windriver.com>
Date:	Thu, 9 Jan 2014 16:24:26 +0800
From:	Fan Du <fan.du@...driver.com>
To:	Ben Hutchings <bhutchings@...arflare.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 2014年01月09日 04:33, Ben Hutchings wrote:
> 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.

Could you please be more specific about this? Thanks.

I'm afraid we can only rearrange structure member order to reduce size
on 64bits, alas that's not feasible here :(

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

-- 
浮沉随浪只记今朝笑

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