netdev - XFRM structures binary compability

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-next>] [day] [month] [year] [list]

Message-ID: <200901121454.21748@centrum.cz>
Date:	Mon, 12 Jan 2009 14:54:46 +0100
From:	<klimes@...trum.cz>
To:	<netdev@...r.kernel.org>
Subject: XFRM structures binary compability

Hello,

I face a problem due to binary incompatibility of XFRM structures.

I use XFRM interface to create IPsec SAs. My user application is compiled as 32bit binary.
It works properly when running against 32bit kernel. However when I've run it on 64bit kernel, netlink returns an error (EINVAL).
I use Fedora for both 32 and 64-bit environment.

I'm aware that it is due to incompatibility (different alignment and padding) of XFRM structures passed between user space and kernel
(defined here for user space: /usr/include/linux/xfrm.h)
My question is: shall not the structures be designed to be the same in 32 and 64bit environment?
I think a padding should be added to meet the more strict alignment rules (i.e. 64bit environment).

I used pahole tool (available in dwarves package) to display structure alignment (see attachment).
pahole_32.txt - structures from 32bit binary
pahole_64.txt - structures from 64bit binary

What causes my trouble is "xfrm_usersa_info" which is padded with 7 bytes at the end in 64-bit,
so that the whole structure is 224 bytes in 64bit application against 220 bytes in 32bit (just 3-byte padding).
An explicit 7-byte padding in the structure would cure the case, IMHO.

Thanks for your comments.

Jiri Klimes

PS: 
David Miller: thanks for pointing me to the correct list.

View attachment "pahole_32.txt" of type "text/plain" (13612 bytes)

View attachment "pahole_64.txt" of type "text/plain" (13911 bytes)