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: <52CE5F21.1070800@windriver.com>
Date:	Thu, 9 Jan 2014 16:34:41 +0800
From:	Fan Du <fan.du@...driver.com>
To:	David Laight <David.Laight@...lab.com>
CC:	Steffen Klassert <steffen.klassert@...unet.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"dev@...ts.strongswan.org" <dev@...ts.strongswan.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct
 xfrm_userpolicy_info



On 2014年01月07日 18:00, David Laight wrote:
>> From: Fan Du
>> >  Sent: 07 January 2014 08:00
>> >  On 2014?01?07? 15:47, Steffen Klassert wrote:
>>> >  >  On Tue, Jan 07, 2014 at 02:48:57PM +0800, Fan Du wrote:
>>>> >  >>  When trying to setup IPsec configuration on a 64bits host with
>>>> >  >>  iproute2(32bits compiled), the intened xfrm policy and sa is
>>>> >  >>  either deficit or wrong when kernel trying to parse user land
>>>> >  >>  information.
>>>> >  >>
>>>> >  >>  Further investigatino shows that:
>>>> >  >>  L: kernel
>>>> >  >>  R: iproute2
>>>> >  >>
>>>> >  >>              sizeof       userpolicy      usersa
>>>> >  >>  64bits(unpacked)        168/168        224/224
>>>> >  >>  32bits(unpacked)        164/164        220/220
>>>> >  >>                             ^   ^
>>>> >  >>                             L   R
>>>> >  >>
>>>> >  >>  To keep kernel and user land see a consistent structure, after
>>>> >  >>  add packing attribute, now it looks like this:
>>>> >  >>
>>>> >  >>  64bits(  packed)        164/164        217/217
>>>> >  >>  32bits(  packed)        164/164        217/217
>>>> >  >>                             ^   ^
>>>> >  >>                             L   R
>>>> >  >>
>>> >  >
>>> >  >  We don't change userspace exported structures. This breaks
>>> >  >  existing userspace tools.
>>> >  >
>> >
>> >  Then user with 32bits iproute2 or StrongSwan has to rebuild as 64bits?
> The kernel has support (in various places) for different structure
> layouts for 32bit and 64bit processes.
> Looks like it needs one here as well (I'm not volunteering though).
>
> At a guess the structures contain a 64bit field that is on an 8n+4
> byte boundary. On i386 64bit fields are only 4 byte aligned, on
> amd64 they are 8 byte aligned.
>
> Packing the structures is definitely wrong. Some 32bit systems (IIRC sparc)
> align 64bit items on 8 byte boundaries. Not to mention the expensive byte
> by byte accesses this forces on some systems.
I don't know much about sparc, if I read your message right, you mean 32bit sparc
system also has padding even if pack attribute is supplied.

And in this scenario, the code path here is only for configuration, i.e., not hot
path, so performance issue is not so crucial here.

>
> The structure could have been defined with the 64bit field marked
> __attribute__((aligned(4))) - so using the same layout on 32bit
> and 64 bit systems , but it is too late to do that now.

Thanks for this useful information.

-- 
浮沉随浪只记今朝笑

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ