Thread (35 messages) 35 messages, 2 authors, 2016-01-13

[PATCH v6 14/21] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

From: arnd@arndb.de (Arnd Bergmann)
Date: 2016-01-08 16:47:01
Also in: lkml

On Friday 08 January 2016 14:13:18 Yury Norov wrote:
On Fri, Jan 08, 2016 at 10:21:06AM +0100, Arnd Bergmann wrote:
quoted
On Friday 08 January 2016 02:34:32 Yury Norov wrote:
quoted
@@ -688,6 +692,12 @@ ni_sys:
    b       ret_fast_syscall
 ENDPROC(el0_svc)
 
+#ifdef CONFIG_ARM64_ILP32
+el0_ilp32_svc:
+   adrp    stbl, sys_call_ilp32_table // load syscall table pointer
+   b el0_svc_naked
+#endif
Don't we still need some code that clears the top halves of the 32-bit
arguments? That thread has taken so many turns now that I'm confused
about what we actually need, but I thought we had concluded that your
current approach has at some some problems.
We are discussing how to do it better - make a generic solution from
s390 with individual syscall handling, or reproduce s390 solution for
ILP32, or zero top-half registers and not use top half of register at
all. As I understand, we stand on 1st option, and agreed to introduce
it separately.
Ok. At some point I thought there was a security hole if we don't
do the explicit expansion, but now I can't remember what I was thinking
of or if that was actually real. Let me try to recall my understanding:

We know that the existing DEFINE_SYSCALL wrappers work fine for
32-bit (__u32, int, unsigned int, ...) or smaller (char, short, __u8,
__u16, ...) arguments as well as the explicitly 64-bit arguments (loff_t,
__u64, __s64). Entering a syscall with a 'long' (or size_t, pointer, ...)
argument means that user space expects the kernel to ignore the upper
half, but the kernel will treat it as part of the register. This means
anything we pass into the kernel will follow the ELF ABI for function
calls, and I don't see a security problem here either, just the question
of how the ABI should be defined.

(sorry for the excursion, I needed to write that down to get my own
thoughts sorted)

I still think that the first option from Catalin's email is best here,
and it would be good if you could implement that so we can see if
there are any complications we have not thought of yet.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help