linux-kernel - Re: [PATCHv3 00/24] ILP32 support in ARM64

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: <20150210181302.GA23886@brightrain.aerifal.cx>
Date:	Tue, 10 Feb 2015 13:13:02 -0500
From:	Rich Felker <dalias@...c.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Andrew Pinski <apinski@...ium.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	pinskia@...il.com, musl@...ts.openwall.com,
	libc-alpha@...rceware.org
Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64

On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
> On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
> > New version with all of the requested changes.  Updated to the
> > latest sources.
> > 
> > Notable changes from the previous versions:
> > VDSO code has been factored out to be easier to understand and
> > easier to maintain.
> > Move the config option to the last thing that gets added.
> > Added some extra COMPAT_* macros for core dumping for easier usage.
> 
> Apart from a few comments I've made, I would also like to see non-empty
> commit logs and long line wrapping (both in commit logs and
> Documentation/). Otherwise, the patches look fine.
> 
> So what are the next steps? Are the glibc folk ok with the ILP32 Linux
> ABI? On the kernel side, what I would like to see:

I don't know if this has been discussed on libc-alpha yet or not, but
I think we need to open a discussion of how it relates to open glibc
bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64):

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

While most of the other type changes proposed (I'm looking at
https://lkml.org/lkml/2014/9/3/719) are permissible and simply
ugly/undesirable, defining struct timespec with tv_nsec having any
type other than long conflicts with the requirements of C11 and POSIX,
and WG14 is unlikely to be interested in changing the C language
because the Linux kernel has the wrong type in timespec.

Note that on aarch64 ILP32, the consequences of not fixing this right
away will be much worse than on x32, since aarch64 (at least as I
understand it) supports big endian where it's not just a matter of
sign-extending the value from userspace and ignoring the padding, but
rather changing the offset of the tv_nsec member.

Working around the discrepencies in userspace IS possible, but ugly.
We do it in musl libc for x32 right now -- see:

http://git.musl-libc.org/cgit/musl/tree/arch/x32/syscall_arch.h?id=v1.1.6
http://git.musl-libc.org/cgit/musl/tree/arch/x32/src/syscall_cp_fixup.c?id=v1.1.6

I imagine the workarounds in glibc might need to be considerably more
widespread and uglier.

Whatever happens on the kernel side, this needs to be coordinated with
userspace (glibc, etc.) properly so that the type error (glibc bug
16437) is not propagated into a new target that we actually want
people to use. I'd really like it if other undesirable type changes
could be cleaned up too, but perhaps that's too much to ask from the
kernel side.

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/