From: ynorov@caviumnetworks.com (Yury Norov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Date: Thu, 7 Jan 2016 18:42:23 +0300 [thread overview]
Message-ID: <20160107154223.GA14532@yury-N73SV> (raw)
In-Reply-To: <2605790.14f8aape6N@wuerfel>
On Thu, Jan 07, 2016 at 03:13:37PM +0100, Arnd Bergmann wrote:
> On Wednesday 06 January 2016 17:10:47 Catalin Marinas wrote:
> > On Tue, Jan 05, 2016 at 10:12:20PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 05 January 2016 18:26:57 Yury Norov wrote:
> > > > > So the calling conventions avoid the problem of being able to set
> > > > > the upper bits from malicious user space when the kernel assumes they
> > > > > are zeroed out (we had security bugs in this area, before we introduced
> > > > > SYSCALL_DEFINEx()), but it means that we need wrappers around each
> > > > > syscall that takes an argument that is different length between user
> > > > > and kernel space (as Catalin guessed). arch/s390 has the same problem and
> > > > > works around it with code in arch/s390/kernel/compat_wrapper.c, while
> > > > > other architectures (at least powerpc, x86 and tile IIRC, don't know much
> > > > > about mips, parisc and sparc) don't have the problem because of their
> > > > > calling conventions.
> > > > >
> > > > > This also means that we cannot work around it in glibc at all, because
> > > > > we have to be able to handle malicious user space, so it has to be
> > > > > done in the kernel using something similar to what s390 does.
> > > >
> > > > So it seems like we (should) have 2 compat modes - with and without access
> > > > to upper half of register. I'm thinking now on how put it in generic
> > > > unistd.h less painfull way.
> > >
> > > I think we can do that by slightly modifying the existing __SYSCALL/__SC_3264/
> > > __SC_COMP/__SC_COMP_3264 macros: The first two need extra wrappers for
> > > arm64-ilp32 and s390, the other two don't.
> > >
> > > We can use some clever string concatenation to add a ##_wrapper to the name
> > > of the handler where needed and then just have a file that implements
> > > the wrappers, copied from s390.
> > >
> > > Unfortunately, we can't just zero out all the upper halves and be done with
> > > it: even if we went back to passing 64-bit arguments as separate 32-bit
> > > registers, we'd still need to deal with sign-extending negative 32-bit
> > > numbers.
> >
> > How many syscalls would we need sign-extension for? Most are probably
> > already handled by specific compat_sys_* functions, otherwise A32 compat
> > wouldn't work properly.
>
> Good point. I suppose any system call that expects a negative argument
> may run into this on all architectures and require a COMPAT_SYSCALL handler,
> but only s390 cares about doing the extension for the entire set of syscalls.
>
> This may be to work around a peculiarity of s390, which has now two
> but three possible 32-to-64 extension modes: signed int, unsigned int
> and pointer. The third one sets the top 33 bits to zero, clearing the
> top bit of the 31-bit pointer value in the process. Nothing else needs
> this, so if we just clear the upper bits on all system calls and go
> back to passing 64-bit arguments as pairs, we are fine and have a much
> simpler solution.
Wrappers will not add extra complexity because we already have it in
s390 port. In other hand, splitting and then assembling 64-bit values
affects performance so small, that we may not care about it much.
So, both approaches are acceptable for me. But I'd choose wrappers,
because it looks more generic, and more fun. :)
This way we can make something like ILP16 easily (can't imagine what
for, though).
>
> > Anyway, I think we can get away with not modifying the generic __SYSCALL
> > definition and only use something like
> > arch/s390/kernel/compat_wrapper.c. In sys_ilp32.c, we would make
> > __SYSCALL expand the function name with some ilp32_ prefix.
>
> I couldn't think of a way, but I'm gladly proven wrong here.
>
> > For existing compat_* syscalls, we only need to handle the pointer types
> > (something like the s390's __TYPE_IS_PTR). I think other types are
> > already handled by defining the prototype with compat_ulong_t etc.
>
> Right.
>
> > For native syscalls like sys_read, apart from pointers we also need to
> > handle size_t. The wrapper would need to be defined using compat types:
> >
> > ILP32_SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, compat_size_t, count)
> >
> > and let the compiler handle the conversion to size_t automatically when
> > calling sys_read from the wrapper.
>
> Correct. I don't think we need an ILP32_SYSCALL_DEFINEx set of macros
> though, the existing COMPAT_SYSCALL_DEFINEx ones should get this right
> already.
>
> Arnd
next prev parent reply other threads:[~2016-01-07 15:42 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-15 21:42 [RFC3 PATCH v6 00/20] ILP32 for ARM64 Yury Norov
2015-12-15 21:42 ` [PATCH v6 01/20] arm64: ilp32: add documentation on the ILP32 ABI " Yury Norov
2015-12-15 21:42 ` [PATCH v6 02/20] arm64: ensure the kernel is compiled for LP64 Yury Norov
2015-12-15 21:42 ` [PATCH v6 03/20] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov
2015-12-17 11:23 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 04/20] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov
2015-12-23 14:15 ` Yury Norov
2015-12-28 8:43 ` > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile Bamvor Jian Zhang
2015-12-28 9:01 ` [PATCH v6 04/20] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Zhangjian (Bamvor)
2015-12-29 12:27 ` Yury Norov
2015-12-29 14:59 ` [PATCH] arm64: compat: fix wrong dependency Bamvor Jian Zhang
2015-12-29 13:12 ` [PATCH v6 04/20] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov
2015-12-15 21:42 ` [PATCH v6 05/20] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Yury Norov
2015-12-15 21:42 ` [PATCH v6 06/20] thread: move thread bits accessors to separated file Yury Norov
2015-12-15 21:42 ` [PATCH v6 07/20] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Yury Norov
2015-12-17 11:38 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 08/20] arm64: ilp32: add is_ilp32_compat_{task, thread} and TIF_32BIT_AARCH64 Yury Norov
2015-12-17 11:41 ` Catalin Marinas
2015-12-18 14:11 ` Yury Norov
2015-12-18 14:44 ` Yury Norov
2015-12-21 17:42 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 09/20] arm64:ilp32: share HWCAP between LP64 and ILP32 Yury Norov
2015-12-16 15:54 ` Arnd Bergmann
2015-12-16 16:58 ` Catalin Marinas
2015-12-16 17:19 ` Catalin Marinas
2015-12-16 19:17 ` Arnd Bergmann
2015-12-17 10:54 ` Catalin Marinas
2015-12-17 13:56 ` Arnd Bergmann
2015-12-15 21:42 ` [PATCH v6 10/20] arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads Yury Norov
2015-12-16 15:50 ` Arnd Bergmann
2015-12-18 13:57 ` Yury Norov
2015-12-15 21:42 ` [PATCH v6 11/20] arm64:ilp32: support core dump generation for ILP32 Yury Norov
2015-12-17 14:05 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov
2015-12-16 16:07 ` Arnd Bergmann
2015-12-17 18:27 ` Catalin Marinas
2015-12-17 20:10 ` Arnd Bergmann
2015-12-17 20:14 ` Andrew Pinski
2015-12-17 20:50 ` Arnd Bergmann
2016-01-05 15:26 ` Yury Norov
2016-01-05 21:12 ` Arnd Bergmann
2016-01-06 17:10 ` Catalin Marinas
2016-01-07 14:13 ` Arnd Bergmann
2016-01-07 15:42 ` Yury Norov [this message]
2016-01-07 17:23 ` Catalin Marinas
2015-12-18 11:42 ` Catalin Marinas
2015-12-18 12:47 ` Arnd Bergmann
2015-12-21 18:31 ` Catalin Marinas
2015-12-21 22:19 ` Arnd Bergmann
2015-12-21 18:39 ` Dr. Philipp Tomsich
2015-12-21 22:13 ` Arnd Bergmann
2015-12-21 22:31 ` Arnd Bergmann
2015-12-23 18:31 ` Yury Norov
2015-12-23 21:48 ` Arnd Bergmann
2015-12-15 21:42 ` [PATCH v6 13/20] arm64: ilp32: share aarch32 syscall wrappers to ilp32 Yury Norov
2015-12-17 14:38 ` Andreas Schwab
2015-12-18 13:49 ` Yury Norov
2015-12-22 12:25 ` Catalin Marinas
2015-12-22 21:44 ` Arnd Bergmann
2015-12-23 13:37 ` Catalin Marinas
2015-12-23 20:41 ` Arnd Bergmann
2015-12-30 17:29 ` Yury Norov
2015-12-30 22:36 ` Arnd Bergmann
2015-12-23 4:21 ` Yury Norov
2015-12-15 21:42 ` [PATCH v6 14/20] arm64: signal: wrap struct ucontext, fp and lr with struct sigframe Yury Norov
2015-12-15 21:42 ` [PATCH v6 15/20] arm64: signal: move ilp32 and lp64 common code to separated file Yury Norov
2015-12-16 16:08 ` Arnd Bergmann
2015-12-18 13:48 ` Yury Norov
2015-12-18 14:09 ` Arnd Bergmann
2015-12-22 17:11 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 16/20] arm64: signal32: move ilp32 and aarch32 " Yury Norov
2015-12-22 14:29 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 17/20] arm64: ilp32: introduce ilp32-specific handlers for sigframe Yury Norov
2015-12-22 17:08 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 18/20] arm64:ilp32: add vdso-ilp32 and use for signal return Yury Norov
2015-12-15 21:42 ` [PATCH v6 19/20] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32 Yury Norov
2015-12-15 21:42 ` [PATCH v6 20/20] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov
2015-12-16 16:24 ` [RFC3 PATCH v6 00/20] ILP32 for ARM64 Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160107154223.GA14532@yury-N73SV \
--to=ynorov@caviumnetworks.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).