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]
Date:	Tue, 7 Jan 2014 10:00:35 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Fan Du' <fan.du@...driver.com>,
	Steffen Klassert <steffen.klassert@...unet.com>
CC:	"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

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

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.

	David

Powered by blists - more mailing lists