qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [ARM/FDPIC 3/4] linux-user: ARM-FDPIC: Add support for


From: Peter Maydell
Subject: Re: [Qemu-devel] [ARM/FDPIC 3/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets
Date: Fri, 13 Apr 2018 16:14:24 +0100

On 6 April 2018 at 16:17, Christophe Lyon <address@hidden> wrote:
> The FDPIC restorer needs to deal with a function descriptor, hence we
> have to extend 'retcode' such that it can hold the instructions needed
> to perform this.
>
> The restorer sequence uses the same thumbness as the exception
> handler (mainly to support Thumb-only architectures).
>
> Co-Authored-By: Mickaël Guêné <address@hidden>
> Signed-off-by: Christophe Lyon <address@hidden>

> +#if defined(CONFIG_USE_FDPIC)
> +/*
> + * Stub needed to make sure the FD register (r9) contains the right
> + * value.
> + */
> +static const unsigned long sigreturn_fdpic_codes[3] = {
> +    0xe59fc004, /* ldr r12, [pc, #4] to read function descriptor */
> +    0xe59c9004, /* ldr r9, [r12, #4] to setup GOT */
> +    0xe59cf000  /* ldr pc, [r12] to jump into restorer */
> +};
> +
> +static const unsigned long sigreturn_fdpic_thumb_codes[3] = {
> +    0xc008f8df, /* ldr r12, [pc, #8] to read function descriptor */
> +    0x9004f8dc, /* ldr r9, [r12, #4] to setup GOT */
> +    0xf000f8dc  /* ldr pc, [r12] to jump into restorer */
> +};
> +#endif
>
>  static inline int valid_user_regs(CPUARMState *regs)
>  {
> @@ -2143,7 +2160,19 @@ setup_return(CPUARMState *env, struct target_sigaction 
> *ka,
>  {
>      abi_ulong handler = ka->_sa_handler;
>      abi_ulong retcode;
> +
> +#ifdef CONFIG_USE_FDPIC
> +    int thumb;
> +
> +    if (env->is_fdpic) {
> +        thumb = (((abi_ulong *)g2h(ka->_sa_handler))[0]) & 1;
> +    } else {
> +        thumb = handler & 1;
> +    }

Dereferencing a pointer obtained by a raw g2h() is very likely
wrong. You want either to use one of the get_user_*() macros, or
a lock_user/__get_user/unlock_user sequence, so that you can
detect whether the guest actually has read access to the address,
and correctly handle the case where it does not.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]