[Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15.

[Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15.

[Mikhail Ilyin]

From: Mikhail Ilyin <m.ilin@samsung.com>

At present there are two copies of TPIDRURO register for secure and unsecure
access. TLS is set via a system call __ARM_NR_set_tls and its handler
(cpu_set_tls) always assigns a provided value to unsecure register
tpidrro_el[0]/tpidruro_ns. But during execution for cortex-a15 mrc instruction
returns TLS from secure rigester tpidruro_s which is 0 and causes SIGSEGV.

Signed-off-by: Mikhail Ilyin <m.ilin@samsung.com>
---
 linux-user/arm/target_cpu.h | 15 ++++++++++++++-
 linux-user/main.c           |  2 +-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/linux-user/arm/target_cpu.h b/linux-user/arm/target_cpu.h
index d8a534d..6832262 100644
--- a/linux-user/arm/target_cpu.h
+++ b/linux-user/arm/target_cpu.h
@@ -29,7 +29,20 @@ static inline void cpu_clone_regs(CPUARMState *env, target_ulong newsp)
 
 static inline void cpu_set_tls(CPUARMState *env, target_ulong newtls)
 {
-    env->cp15.tpidrro_el[0] = newtls;
+    if (access_secure_reg(env)) {
+        env->cp15.tpidruro_s = newtls;
+    } else {
+        env->cp15.tpidrro_el[0] = newtls;
+    }
+}
+
+static inline target_ulong cpu_get_tls(CPUARMState *env)
+{
+    if (access_secure_reg(env)) {
+        return env->cp15.tpidruro_s;
+    } else {
+        return env->cp15.tpidrro_el[0];
+    }
 }
 
 #endif
diff --git a/linux-user/main.c b/linux-user/main.c
index 6bd23af..6e446de 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -566,7 +566,7 @@ do_kernel_trap(CPUARMState *env)
         end_exclusive();
         break;
     case 0xffff0fe0: /* __kernel_get_tls */
-        env->regs[0] = env->cp15.tpidrro_el[0];
+        env->regs[0] = cpu_get_tls(env);
         break;
     case 0xffff0f60: /* __kernel_cmpxchg64 */
         arm_kernel_cmpxchg64_helper(env);
-- 
1.9.1

Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15.

[Mikhail Ilin]

Here is a sample to prove the issue

$ echo "int main() { return 0; }" > /tmp/prog.c
$ arm-linux-gnueabi-gcc -g -o /tmp/prog /tmp/prog.c
$ qemu-arm -cpu cortex-a15 -L 
/home/michail/arm/arm-linux-gnueabi/sys-root /tmp/prog
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

prog backtrace look the following way

$ qemu-arm -g 1234 -cpu cortex-a15 -L 
/home/michail/arm/arm-linux-gnueabi/sys-root /tmp/prog

$ arm-linux-gnueabi-gdb -ex 'set sysroot 
/home/michail/arm/arm-linux-gnueabi/sys-root/' -ex 'file /tmp/prog' -ex 
'target remote :1234'
(gdb) c

Program received signal SIGSEGV, Segmentation fault.
0xf6690290 in __GI___ctype_init () at ctype-info.c:31
31        *bp = (const uint16_t *) _NL_CURRENT (LC_CTYPE, 
_NL_CTYPE_CLASS) + 128;
(gdb) bt
#0  0xf6690290 in __GI___ctype_init () at ctype-info.c:31
#1  0xf67e62e4 in call_init (l=0xf67d5708, argc=1, argv=0xf6ffef14, 
env=0xf6ffef1c) at dl-init.c:69
#2  0xf67e6434 in _dl_init (main_map=0xf67fe960, argc=1, 
argv=0xf6ffef14, env=0xf6ffef1c) at dl-init.c:132
#3  0xf67d6d74 in _dl_start_user () from 
/home/michail/arm/arm-linux-gnueabi/sys-root/lib/ld-linux.so.3
(gdb) disassemble
Dump of assembler code for function __GI___ctype_init:
    0xf669026c <+0>:     ldr     r12, [pc, #88]  ; 0xf66902cc 
<__GI___ctype_init+96>
    0xf6690270 <+4>:     strd    r4, [sp, #-12]!
    0xf6690274 <+8>:     mrc     15, 0, r3, cr13, cr0, {3}
    0xf6690278 <+12>:    str     lr, [sp, #8]
    0xf669027c <+16>:    ldr     r0, [pc, #76]   ; 0xf66902d0 
<__GI___ctype_init+100>
    0xf6690280 <+20>:    ldr     r1, [pc, #76]   ; 0xf66902d4 
<__GI___ctype_init+104>
    0xf6690284 <+24>:    ldr     r2, [pc, #76]   ; 0xf66902d8 
<__GI___ctype_init+108>
    0xf6690288 <+28>:    ldr     r12, [pc, r12]
    0xf669028c <+32>:    ldr     r0, [pc, r0]
=> 0xf6690290 <+36>:    ldr     r12, [r3, r12]
    0xf6690294 <+40>:    ldr     r12, [r12]
(gdb) p $r3
$1 = 0

Register r3 comes from mrc and should contain pointer to TLS. In runtime
cp15.tpidruro_ns contains a valid pointer that is assigned with
__ARM_NR_set_tls, cp.tpidruro_s is 0 and its value is returned with mrc.

-- Mikhail

On 16.03.2015 14:26, Mikhail Ilyin wrote:
> From: Mikhail Ilyin <m.ilin@samsung.com>
>
> At present there are two copies of TPIDRURO register for secure and unsecure
> access. TLS is set via a system call __ARM_NR_set_tls and its handler
> (cpu_set_tls) always assigns a provided value to unsecure register
> tpidrro_el[0]/tpidruro_ns. But during execution for cortex-a15 mrc instruction
> returns TLS from secure rigester tpidruro_s which is 0 and causes SIGSEGV.
>
> Signed-off-by: Mikhail Ilyin <m.ilin@samsung.com>
> ---
>   linux-user/arm/target_cpu.h | 15 ++++++++++++++-
>   linux-user/main.c           |  2 +-
>   2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/linux-user/arm/target_cpu.h b/linux-user/arm/target_cpu.h
> index d8a534d..6832262 100644
> --- a/linux-user/arm/target_cpu.h
> +++ b/linux-user/arm/target_cpu.h
> @@ -29,7 +29,20 @@ static inline void cpu_clone_regs(CPUARMState *env, target_ulong newsp)
>
>   static inline void cpu_set_tls(CPUARMState *env, target_ulong newtls)
>   {
> -    env->cp15.tpidrro_el[0] = newtls;
> +    if (access_secure_reg(env)) {
> +        env->cp15.tpidruro_s = newtls;
> +    } else {
> +        env->cp15.tpidrro_el[0] = newtls;
> +    }
> +}
> +
> +static inline target_ulong cpu_get_tls(CPUARMState *env)
> +{
> +    if (access_secure_reg(env)) {
> +        return env->cp15.tpidruro_s;
> +    } else {
> +        return env->cp15.tpidrro_el[0];
> +    }
>   }
>
>   #endif
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 6bd23af..6e446de 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -566,7 +566,7 @@ do_kernel_trap(CPUARMState *env)
>           end_exclusive();
>           break;
>       case 0xffff0fe0: /* __kernel_get_tls */
> -        env->regs[0] = env->cp15.tpidrro_el[0];
> +        env->regs[0] = cpu_get_tls(env);
>           break;
>       case 0xffff0f60: /* __kernel_cmpxchg64 */
>           arm_kernel_cmpxchg64_helper(env);
>

Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15.

[Peter Maydell]

On 16 March 2015 at 11:26, Mikhail Ilyin <m.ilin@samsung.com> wrote:
> From: Mikhail Ilyin <m.ilin@samsung.com>
>
> At present there are two copies of TPIDRURO register for secure and unsecure
> access. TLS is set via a system call __ARM_NR_set_tls and its handler
> (cpu_set_tls) always assigns a provided value to unsecure register
> tpidrro_el[0]/tpidruro_ns. But during execution for cortex-a15 mrc instruction
> returns TLS from secure rigester tpidruro_s which is 0 and causes SIGSEGV.
>
> Signed-off-by: Mikhail Ilyin <m.ilin@samsung.com>

Oops; thanks for this patch. I've applied it to target-arm.next.
I took the liberty of rewriting the commit message a bit to better
fit in with QEMU's usual style; hope that's OK:

===begin===
linux-user: Access correct register for get/set_tls syscalls on ARM TZ CPUs

When support was added for TrustZone to ARM CPU emulation, we failed
to correctly update the support for the linux-user implementation of
the get/set_tls syscalls. This meant that accesses to the TPIDRURO
register via the syscalls were always using the non-secure copy of
the register even if native MRC/MCR accesses were using the secure
register. This inconsistency caused most binaries to segfault on startup
if the CPU type was explicitly set to one of the TZ-enabled ones like
cortex-a15. (The default "any" CPU doesn't have TZ enabled and so is
not affected.)

Use access_secure_reg() to determine whether we should be using
the secure or the nonsecure copy of TPIDRURO when emulating these
syscalls.
===endit===

-- PMM

Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15.

[Mikhail Ilin]

On 16.03.2015 15:05, Peter Maydell wrote:
> I took the liberty of rewriting the commit message a bit to better
> fit in with QEMU's usual style; hope that's OK:

Sure, it is fine :)

-- Mikhail