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]

Message-ID: <3662254.2ZhTAQGuKR@wuerfel>
Date:	Mon, 20 Apr 2015 19:40:37 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Andreas Kraschitzer <andreas.kraschitzer@...obroma-systems.com>,
	Benedikt Huber <benedikt.huber@...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>,
	"ksankaran@....com" <ksankaran@....com>,
	"philipp.tomsich@...obroma-systems.com" 
	<philipp.tomsich@...obroma-systems.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Christoph Muellner <christoph.muellner@...obroma-systems.com>
Subject: Re: [PATCH v4 00/24] ILP32 for ARM64

On Monday 20 April 2015 16:56:00 Catalin Marinas wrote:
> On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
> > On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> > > On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > | typedef unsigned short          __kernel_mode_t;
> > | typedef unsigned short          __kernel_ipc_pid_t;
> > 
> > Both of these affect all sysvipc, but very little else
> > 
> > | typedef unsigned short          __kernel_uid_t;
> > | typedef unsigned short          __kernel_gid_t;
> > 
> > sysvipc, ncpfs, and core dumps (probably fine since they are separate
> > anyway), 
> 
> Not all ipc functions are affected AFAICT. msgsnd, msgrcv, msgctl look
> to me like we can just use the compat variants with the generic
> definitions for the types above (unless I missed something). Similarly
> for shmat, compat_sys_shmat just does some compat_ptr casting.

Right.

> > | typedef unsigned short          __kernel_old_dev_t; /* compat gets this wrong */
> > 
> > old-style loopdev ioctl
> > 
> > | struct stat { ... } /* possibly not needed */
> > 
> >  - lustre ioctls (needs to be fixed anyway)
> >  - old stat syscalls (won't be used with asm-generic/unistd.h)
> > 
> > | struct stat64 { ... }
> > 
> >  - lustre ioctls
> >  - new style stat syscalls
> 
> For stat64 the wrappers don't look complicated, so we could add arm64
> ILP32-specific ones.

stat is never easy ;-)

Note that for new architectures, we use 'struct stat64' on 32-bit systems
but 'struct stat' on 64-bit systems. Old architectures like arch/arm has
both, and neither of them matches the on from arch/arm64.

Also, the asm-generic definition of 'struct stat64' is wrong and really
needs to be fixed to have the same layout that 'struct stat' has on
a 64-bit architecture. The only difference between the two is the size
of the time related 'st_atime' etc members, and having them defined
this way was my biggest mistake when I created the uapi/asm-generic
headers.

> > So, in essence the difference comes down to the syscalls for stat
> > and ipc. If we use the aarch32 data types, we can share the
> > fstatat64, fstat64, semctl, msgsnd, msgrcv, msgctl, shmat,
> > and shmctl compat system calls between aarch32-compat and
> > aarch64-ilp32-compat. Otherwise we have to duplicate or extend
> > them to cover both cases at runtime. That would be rather ugly
> > but entirely doable. The ioctls are hardly affected, the few
> > ones that differ once __kernel_long_t matches could easily be
> > fixed up as you say.
> 
> I'd prefer a cleaner ABI even if we are to write some specific wrappers.

Ok, makes sense. As I replied to Philipp later, even with the
cleaner definition of 'stat64' and the sysipc syscalls, we should
be able to trivially reuse the native 64-bit version in the way that
the current patch set does for a lot of other syscalls, but keep all
the other syscalls using the normal 32-bit __kernel_long_t variants
that we already have.

	Arnd
--
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/