linux-kernel - RE: [PATCH 0/4] Make xfrm usable by 32-bit programs

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: <063D6719AE5E284EB5DD2968C1650D6DB026BC58@AcuExch.aculab.com>
Date:   Mon, 23 Jan 2017 16:45:39 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Kevin Cernekee' <cernekee@...omium.org>,
        "steffen.klassert@...unet.com" <steffen.klassert@...unet.com>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "paul@...l-moore.com" <paul@...l-moore.com>,
        "sds@...ho.nsa.gov" <sds@...ho.nsa.gov>,
        "eparis@...isplace.org" <eparis@...isplace.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "selinux@...ho.nsa.gov" <selinux@...ho.nsa.gov>,
        "fw@...len.de" <fw@...len.de>,
        "fan.du@...driver.com" <fan.du@...driver.com>,
        "dianders@...omium.org" <dianders@...omium.org>,
        "dtor@...omium.org" <dtor@...omium.org>
Subject: RE: [PATCH 0/4] Make xfrm usable by 32-bit programs

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