* [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15. @ 2015-03-16 11:26 Mikhail Ilyin 2015-03-16 11:32 ` Mikhail Ilin 2015-03-16 12:05 ` Peter Maydell 0 siblings, 2 replies; 4+ messages in thread From: Mikhail Ilyin @ 2015-03-16 11:26 UTC (permalink / raw) To: qemu-devel; +Cc: m.ilin, riku.voipio, y.gribov 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15. 2015-03-16 11:26 [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15 Mikhail Ilyin @ 2015-03-16 11:32 ` Mikhail Ilin 2015-03-16 12:05 ` Peter Maydell 1 sibling, 0 replies; 4+ messages in thread From: Mikhail Ilin @ 2015-03-16 11:32 UTC (permalink / raw) To: qemu-devel; +Cc: riku.voipio 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); > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15. 2015-03-16 11:26 [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15 Mikhail Ilyin 2015-03-16 11:32 ` Mikhail Ilin @ 2015-03-16 12:05 ` Peter Maydell 2015-03-16 12:14 ` Mikhail Ilin 1 sibling, 1 reply; 4+ messages in thread From: Peter Maydell @ 2015-03-16 12:05 UTC (permalink / raw) To: Mikhail Ilyin; +Cc: Greg Bellows, Riku Voipio, QEMU Developers, Yury Gribov 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15. 2015-03-16 12:05 ` Peter Maydell @ 2015-03-16 12:14 ` Mikhail Ilin 0 siblings, 0 replies; 4+ messages in thread From: Mikhail Ilin @ 2015-03-16 12:14 UTC (permalink / raw) To: Peter Maydell; +Cc: Greg Bellows, Riku Voipio, QEMU Developers, Yury Gribov 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-03-16 12:13 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-03-16 11:26 [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15 Mikhail Ilyin 2015-03-16 11:32 ` Mikhail Ilin 2015-03-16 12:05 ` Peter Maydell 2015-03-16 12:14 ` Mikhail Ilin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.