From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751233AbdAWQpz convert rfc822-to-8bit (ORCPT ); Mon, 23 Jan 2017 11:45:55 -0500 Received: from smtp-out4.electric.net ([192.162.216.185]:51098 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbdAWQpv (ORCPT ); Mon, 23 Jan 2017 11:45:51 -0500 From: David Laight To: "'Kevin Cernekee'" , "steffen.klassert@secunet.com" , "herbert@gondor.apana.org.au" , "davem@davemloft.net" , "paul@paul-moore.com" , "sds@tycho.nsa.gov" , "eparis@parisplace.org" CC: "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "selinux@tycho.nsa.gov" , "fw@strlen.de" , "fan.du@windriver.com" , "dianders@chromium.org" , "dtor@chromium.org" Subject: RE: [PATCH 0/4] Make xfrm usable by 32-bit programs Thread-Topic: [PATCH 0/4] Make xfrm usable by 32-bit programs Thread-Index: AQHSc3o4TV0+A0I87kq5ha0M/yEnb6FGRgsA Date: Mon, 23 Jan 2017 16:45:39 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB026BC58@AcuExch.aculab.com> References: <20170121000507.34381-1-cernekee@chromium.org> In-Reply-To: <20170121000507.34381-1-cernekee@chromium.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Kevin Cernekee > Sent: 21 January 2017 00:05 > Several of the xfrm netlink and setsockopt() interfaces are not usable > from a 32-bit binary running on a 64-bit kernel due to struct padding > differences. This has been the case for many, many years[0]. This > patch series deprecates the broken netlink messages and replaces them > with packed structs that are compatible between 64-bit and 32-bit > programs. Do you mean '__packed' or just structures with no holes? The latter is really the best. You can add a compile time assert on the structure sizes to ensure that the user API is never accidentally broken. I can't imagine any reason to change the 64bit structures except (maybe) to make any padding explicit. > It retains support for legacy user programs (i.e. anything > that is currently working today), and allows legacy support to be > compiled out via CONFIG_XFRM_USER_LEGACY if it becomes unnecessary in > the future. ... Isn't that effectively the same as doing a compat layer? Otherwise you can't build a 32bit app that will work with an 'old' 32bit kernel and a new 64bit one. Provided you've got the length of the user's buffer the compat code ought to be trivial (if tedious). David