linux-kernel - Re: [PATCH v4 00/24] ILP32 for 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]

Date:	Fri, 17 Apr 2015 17:15:46 +0200
From:	"Dr. Philipp Tomsich" <philipp.tomsich@...obroma-systems.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Andreas Kraschitzer <andreas.kraschitzer@...obroma-systems.com>,
	"Pinski, Andrew" <Andrew.Pinski@...iumnetworks.com>,
	Andreas Schwab <schwab@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"agraf@...e.de" <agraf@...e.de>,
	Andrew Pinski <apinski@...ium.com>,
	Kumar Sankaran <ksankaran@....com>,
	Benedikt Huber <benedikt.huber@...obroma-systems.com>,
	Christoph Muellner <christoph.muellner@...obroma-systems.com>
Subject: Re: [PATCH v4 00/24] ILP32 for ARM64

More comments below.

> On 17 Apr 2015, at 16:46, Catalin Marinas <catalin.marinas@....com> wrote:
> 
> Even in this case, we could enable AArch32 compat knowing that ioctls
> wouldn't work. If this is important, we can add an option to enable
> ioctl support for ILP32 and re-target the asm/compat.h definitions.
> 
>>  g) create a new ABI that does things in exactly the way that we
>>     would use as the native syscall interface if we had an ilp32
>>     kernel running on aarch64 with the asm-generic/unistd.h.
>>     This would mean a 32-bit __kernel_long_t and time_t, but extending
>>     time_t in the long run, together with aarch32 and i386.
>>     This one is particularly interesting for people that are interested
>>     in maximum posix compliance and in having a "nice" ABI, in particular
>>     if there is a slight chance that within the next decade we have
>>     reason to support building an arch/arm64 kernel itself in
>>     aarch64-ilp32 mode.

I don’t believe that an ILP32 kernel wouldn’t use an uint64_t for time_t, as it
has full support for 64bit arithmetic anyway.  I also believe that other kernel 
internals (e.g. filesystems and inode-numbering) would use native 64bit types.

The differences on the kernel side would mainly rest in that only a 32bit address
space could reasonably be managed. So a native ILP32 ABI would differ from
the LP64 ABI mainly in how sizeof(long) is represented in the user-space.

In other works: a native ILP32 ABI on an ILP32 kernel would have a 64bit time_t.

>>>> However, it would be nice to get agreement on the normal 32-bit ABI
>>>> for time_t and timespec first, and then use the same thing everywhere.
>>> 
>>> Do you mean for native 32-bit architectures? I think OpenBSD uses a
>>> 64-bit time_t already on 32-bit arches, it's doable in Linux as well.
>> 
>> Yes, and I'm working on that for Linux. The first step involves fixing
>> the kernel, one file at a time, changing all users of time_t to use
>> some other type (ktime_t or time64_t in most cases) instead, and introducing
>> additional system calls to handle the boundary to user space without
>> breaking stuff. See my presentation at http://elinux.org/ELC_2015_Presentations
>> for more detail.
> 
> The approach here is primarily to fix the problem for existing 32-bit
> architectures by adding a new syscall and that's fine. But what if we
> enforce 64-bit time_t for all _new_ architectures?

This boils down to whether we can define all the new syscalls _right now_ and
get the new (extended) compat-layer set up. In this case we could have a userspace 
implementation that already conforms to this for ILP32.

Otherwise, we can just put a (MIPS64) N32-alike (AArch64) ILP32 in and migrate
with everyone else.

Although it feels wrong to add another ABI that has a known limitation, this may
in fact be the easiest way, as any fix to ILP32 would be done together with the
fixes to all other 32bit ABIs.

So, while I would like to have a 64bit time_t for ILP32 based on principle, I do see
the 32bit time_t path as the most pragmatic way forward… especially, as this unlinks
getting “some form of” ILP32 merged from resolving the 64bit time_t issue across
all architectures.

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