include/elf.h | 1 + linux-user/elfload.c | 54 ++++++++++++++++++++------ linux-user/qemu.h | 13 ++++++- linux-user/signal.c | 105 +++++++++++++++++++++++++++++++++++++++++++-------- 4 files changed, 144 insertions(+), 29 deletions(-)
Hello, This patch series implements the QEMU contribution of the FDPIC ABI for ARM targets. This ABI enables to run Linux on ARM MMU-less cores and supports shared libraries to reduce the memory footprint. Without MMU, text and data segment relative distances are different from one process to another, hence the need for a dedicated FDPIC register holding the start address of the data segment. One of the side effects is that function pointers require two words to be represented: the address of the code, and the data segment start address. These two words are designated as "Function Descriptor", hence the "FD PIC" name. On ARM, the FDPIC register is r9 [3]. This work was developed some time ago by STMicroelectronics, and was presented during Linaro Connect SFO15 (September 2015). You can watch the discussion and read the slides [1]. This presentation was related to the toolchain published on github [2], which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1 and qemu-2.3.0, and for which pre-built binaries are available [2]. The ABI itself is described in details in [3]. Our Linux kernel patches have been updated and committed by Nicolas Pitre (Linaro) in July 2017. They are required so that the loader is able to handle this new file type. Indeed, the ELF files are tagged with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as well as the new relocations involved. This patch series has been rebased on top of QEMU from 2018-03-28. I have also rebased the GCC patch series, but it is still WIP as cleanup is still needed before I can request a review. It can be useful to build a preview toolchain though, so my WIP branch is available at [4]. To build such a toolchain, you'd also need to use my uClibc branch [5]. I am currently working on updating the patches for the other toolchain components, and will upstream them soon. This includes gcc, uclibc, and gdb. This series provides support for ARM v7 and later architectures and has been used to run the GCC tests on arm-linux-gnueabi without regression, as well as arm-linux-uclibceabi. v3->v4: - Fix nits in patch #3. v2->v3: - Do not add the is_fdpic field to TaskState, as the information can be retrieved from the 'info' data in TaskState. - Setup_return() now returns an error if the FDPIC function description isn't readable. Callers of setup_return() are updated to force_sigsegv in such cases. v1->v2: - Patch #1 removes CONFIG_USE_FDPIC - Patch #2 corresponds to the previous patch #1, and is now simpler without configure option - Patch #3 corresponds to the previous patch #2, and uses TaskState instead of CPUARMState - patch #4 corresponds to the previous patch #3, and fixes guest pointer dereferencing Are the QEMU patches OK for inclusion in master? Thanks, Christophe. [1] http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/ [2] https://github.com/mickael-guene/fdpic_manifest [3] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt [4] https://git.linaro.org/people/christophe.lyon/gcc.git/log/?h=fdpic-upstream [5] https://git.linaro.org/people/christophe.lyon/uclibc.git/log/?h=uClibc-0.9.33.2-fdpic-upstream Christophe Lyon (4): Remove CONFIG_USE_FDPIC. linux-user: ARM-FDPIC: Identify ARM FDPIC binaries linux-user: ARM-FDPIC: Add support of FDPIC for ARM. linux-user: ARM-FDPIC: Add support for signals for FDPIC targets include/elf.h | 1 + linux-user/elfload.c | 54 ++++++++++++++++++++------ linux-user/qemu.h | 13 ++++++- linux-user/signal.c | 105 +++++++++++++++++++++++++++++++++++++++++++-------- 4 files changed, 144 insertions(+), 29 deletions(-) -- 2.6.3
On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote: > Hello, > > This patch series implements the QEMU contribution of the FDPIC > ABI for ARM targets. Hi; I definitely reviewed at least some of these patches, but this respin seems to have lost all the reviewed-by tags? thanks -- PMM
On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote: > On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote: >> Hello, >> >> This patch series implements the QEMU contribution of the FDPIC >> ABI for ARM targets. > > Hi; I definitely reviewed at least some of these patches, > but this respin seems to have lost all the reviewed-by tags? > Indeed, I failed to include them. Shall I send a v5 including these tags? Sorry, Christophe > thanks > -- PMM
On 30 April 2018 at 09:40, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote: >>> Hello, >>> >>> This patch series implements the QEMU contribution of the FDPIC >>> ABI for ARM targets. >> >> Hi; I definitely reviewed at least some of these patches, >> but this respin seems to have lost all the reviewed-by tags? >> > Indeed, I failed to include them. > Shall I send a v5 including these tags? No, but if you can check which ones should have them that would be helpful. thanks -- PMM
On 30 April 2018 at 10:59, Peter Maydell <peter.maydell@linaro.org> wrote: > On 30 April 2018 at 09:40, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote: >>>> Hello, >>>> >>>> This patch series implements the QEMU contribution of the FDPIC >>>> ABI for ARM targets. >>> >>> Hi; I definitely reviewed at least some of these patches, >>> but this respin seems to have lost all the reviewed-by tags? >>> >> Indeed, I failed to include them. >> Shall I send a v5 including these tags? > > No, but if you can check which ones should have them that would > be helpful. > OK, so all 4 patches have Reviewed-by: Peter Maydell <peter.maydell@linaro.org> (you added it to patch 3/4, provided I fixed the nits, which I did in v4). Thanks Christophe > thanks > -- PMM
On 30 April 2018 at 10:08, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 30 April 2018 at 10:59, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 30 April 2018 at 09:40, Christophe Lyon <christophe.lyon@linaro.org> wrote: >>> On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote: >>>> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote: >>>>> Hello, >>>>> >>>>> This patch series implements the QEMU contribution of the FDPIC >>>>> ABI for ARM targets. >>>> >>>> Hi; I definitely reviewed at least some of these patches, >>>> but this respin seems to have lost all the reviewed-by tags? >>>> >>> Indeed, I failed to include them. >>> Shall I send a v5 including these tags? >> >> No, but if you can check which ones should have them that would >> be helpful. >> > OK, so all 4 patches have > Reviewed-by: Peter Maydell <peter.maydell@linaro.org> > (you added it to patch 3/4, provided I fixed the nits, which I did in v4). Great. Riku/Laurent -- I'm assuming you're going to take this set via the linux-user tree. -- PMM
Le 30/04/2018 à 11:12, Peter Maydell a écrit : > On 30 April 2018 at 10:08, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> On 30 April 2018 at 10:59, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 30 April 2018 at 09:40, Christophe Lyon <christophe.lyon@linaro.org> wrote: >>>> On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote: >>>>> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote: >>>>>> Hello, >>>>>> >>>>>> This patch series implements the QEMU contribution of the FDPIC >>>>>> ABI for ARM targets. >>>>> >>>>> Hi; I definitely reviewed at least some of these patches, >>>>> but this respin seems to have lost all the reviewed-by tags? >>>>> >>>> Indeed, I failed to include them. >>>> Shall I send a v5 including these tags? >>> >>> No, but if you can check which ones should have them that would >>> be helpful. >>> >> OK, so all 4 patches have >> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> >> (you added it to patch 3/4, provided I fixed the nits, which I did in v4). > > Great. Riku/Laurent -- I'm assuming you're going to take this set > via the linux-user tree. I just sent a pull request without it... Do you prefer I update this one or I send another one later? Thanks, Laurent
On 30 April 2018 at 10:28, Laurent Vivier <laurent@vivier.eu> wrote: > Le 30/04/2018 à 11:12, Peter Maydell a écrit : >> Great. Riku/Laurent -- I'm assuming you're going to take this set >> via the linux-user tree. > > I just sent a pull request without it... > > Do you prefer I update this one or I send another one later? No, it can go into your next one I think. I see you've sent the signal.c refactoring, which this will conflict with, so either you or Christophe will need to rebase it anyway. thanks -- PMM
Le 30/04/2018 à 11:46, Peter Maydell a écrit : > On 30 April 2018 at 10:28, Laurent Vivier <laurent@vivier.eu> wrote: >> Le 30/04/2018 à 11:12, Peter Maydell a écrit : >>> Great. Riku/Laurent -- I'm assuming you're going to take this set >>> via the linux-user tree. >> >> I just sent a pull request without it... >> >> Do you prefer I update this one or I send another one later? > > No, it can go into your next one I think. I see you've sent > the signal.c refactoring, which this will conflict with, > so either you or Christophe will need to rebase it anyway. Yes, I will. Thanks, Laurent
Le 30/04/2018 à 11:46, Peter Maydell a écrit : > On 30 April 2018 at 10:28, Laurent Vivier <laurent@vivier.eu> wrote: >> Le 30/04/2018 à 11:12, Peter Maydell a écrit : >>> Great. Riku/Laurent -- I'm assuming you're going to take this set >>> via the linux-user tree. >> >> I just sent a pull request without it... >> >> Do you prefer I update this one or I send another one later? > > No, it can go into your next one I think. I see you've sent > the signal.c refactoring, which this will conflict with, > so either you or Christophe will need to rebase it anyway. > > thanks > -- PMM > OK, I've rebased the series on top of the new master and applied to my branch linux-user-for-2.13 (see https://github.com/vivier/qemu/tree/linux-user-for-2.13) Thanks, Laurent
On 30 April 2018 at 14:03, Laurent Vivier <laurent@vivier.eu> wrote: > Le 30/04/2018 à 11:46, Peter Maydell a écrit : >> On 30 April 2018 at 10:28, Laurent Vivier <laurent@vivier.eu> wrote: >>> Le 30/04/2018 à 11:12, Peter Maydell a écrit : >>>> Great. Riku/Laurent -- I'm assuming you're going to take this set >>>> via the linux-user tree. >>> >>> I just sent a pull request without it... >>> >>> Do you prefer I update this one or I send another one later? >> >> No, it can go into your next one I think. I see you've sent >> the signal.c refactoring, which this will conflict with, >> so either you or Christophe will need to rebase it anyway. >> >> thanks >> -- PMM >> > > OK, I've rebased the series on top of the new master and applied to my > branch linux-user-for-2.13 > (see https://github.com/vivier/qemu/tree/linux-user-for-2.13) > For the record, I ran a smoke test with this branch and my small example with a signal handler worked as expected. Thanks, Christophe > Thanks, > Laurent
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é <mickael.guene@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@st.com>
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 8d9e6e8..6dbc699 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2045,13 +2045,13 @@ struct sigframe_v1
{
struct target_sigcontext sc;
abi_ulong extramask[TARGET_NSIG_WORDS-1];
- abi_ulong retcode;
+ abi_ulong retcode[4];
};
struct sigframe_v2
{
struct target_ucontext_v2 uc;
- abi_ulong retcode;
+ abi_ulong retcode[4];
};
struct rt_sigframe_v1
@@ -2060,14 +2060,14 @@ struct rt_sigframe_v1
abi_ulong puc;
struct target_siginfo info;
struct target_ucontext_v1 uc;
- abi_ulong retcode;
+ abi_ulong retcode[4];
};
struct rt_sigframe_v2
{
struct target_siginfo info;
struct target_ucontext_v2 uc;
- abi_ulong retcode;
+ abi_ulong retcode[4];
};
#define TARGET_CONFIG_CPU_32 1
@@ -2090,6 +2090,21 @@ static const abi_ulong retcodes[4] = {
SWI_SYS_RT_SIGRETURN, SWI_THUMB_RT_SIGRETURN
};
+/*
+ * 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 */
+};
static inline int valid_user_regs(CPUARMState *regs)
{
@@ -2143,13 +2158,33 @@ get_sigframe(struct target_sigaction *ka, CPUARMState *regs, int framesize)
return (sp - framesize) & ~7;
}
-static void
+static int
setup_return(CPUARMState *env, struct target_sigaction *ka,
abi_ulong *rc, abi_ulong frame_addr, int usig, abi_ulong rc_addr)
{
- abi_ulong handler = ka->_sa_handler;
+ abi_ulong handler = 0;
+ abi_ulong handler_fdpic_GOT = 0;
abi_ulong retcode;
- int thumb = handler & 1;
+
+ int thumb;
+ int is_fdpic = info_is_fdpic(((TaskState *)thread_cpu->opaque)->info);
+
+ if (is_fdpic) {
+ /* In FDPIC mode, ka->_sa_handler points to a function
+ * descriptor (FD). The first word contains the address of the
+ * handler. The second word contains the value of the PIC
+ * register (r9). */
+ abi_ulong funcdesc_ptr = ka->_sa_handler;
+ if (get_user_ual(handler, funcdesc_ptr)
+ || get_user_ual(handler_fdpic_GOT, funcdesc_ptr + 4)) {
+ return 1;
+ }
+ } else {
+ handler = ka->_sa_handler;
+ }
+
+ thumb = handler & 1;
+
uint32_t cpsr = cpsr_read(env);
cpsr &= ~CPSR_IT;
@@ -2160,7 +2195,28 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
}
if (ka->sa_flags & TARGET_SA_RESTORER) {
- retcode = ka->sa_restorer;
+ if (is_fdpic) {
+ /* For FDPIC we ensure that the restorer is called with a
+ * correct r9 value. For that we need to write code on
+ * the stack that sets r9 and jumps back to restorer
+ * value.
+ */
+ if (thumb) {
+ __put_user(sigreturn_fdpic_thumb_codes[0], rc);
+ __put_user(sigreturn_fdpic_thumb_codes[1], rc + 1);
+ __put_user(sigreturn_fdpic_thumb_codes[2], rc + 2);
+ __put_user((abi_ulong)ka->sa_restorer, rc + 3);
+ } else {
+ __put_user(sigreturn_fdpic_codes[0], rc);
+ __put_user(sigreturn_fdpic_codes[1], rc + 1);
+ __put_user(sigreturn_fdpic_codes[2], rc + 2);
+ __put_user((abi_ulong)ka->sa_restorer, rc + 3);
+ }
+
+ retcode = rc_addr + thumb;
+ } else {
+ retcode = ka->sa_restorer;
+ }
} else {
unsigned int idx = thumb;
@@ -2174,10 +2230,15 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
}
env->regs[0] = usig;
+ if (is_fdpic) {
+ env->regs[9] = handler_fdpic_GOT;
+ }
env->regs[13] = frame_addr;
env->regs[14] = retcode;
env->regs[15] = handler & (thumb ? ~1 : ~3);
cpsr_write(env, cpsr, CPSR_IT | CPSR_T, CPSRWriteByInstr);
+
+ return 0;
}
static abi_ulong *setup_sigframe_v2_vfp(abi_ulong *regspace, CPUARMState *env)
@@ -2270,12 +2331,15 @@ static void setup_frame_v1(int usig, struct target_sigaction *ka,
__put_user(set->sig[i], &frame->extramask[i - 1]);
}
- setup_return(regs, ka, &frame->retcode, frame_addr, usig,
- frame_addr + offsetof(struct sigframe_v1, retcode));
+ if (setup_return(regs, ka, frame->retcode, frame_addr, usig,
+ frame_addr + offsetof(struct sigframe_v1, retcode))) {
+ goto sigsegv;
+ }
unlock_user_struct(frame, frame_addr, 1);
return;
sigsegv:
+ unlock_user_struct(frame, frame_addr, 1);
force_sigsegv(usig);
}
@@ -2292,12 +2356,15 @@ static void setup_frame_v2(int usig, struct target_sigaction *ka,
setup_sigframe_v2(&frame->uc, set, regs);
- setup_return(regs, ka, &frame->retcode, frame_addr, usig,
- frame_addr + offsetof(struct sigframe_v2, retcode));
+ if (setup_return(regs, ka, frame->retcode, frame_addr, usig,
+ frame_addr + offsetof(struct sigframe_v2, retcode))) {
+ goto sigsegv;
+ }
unlock_user_struct(frame, frame_addr, 1);
return;
sigsegv:
+ unlock_user_struct(frame, frame_addr, 1);
force_sigsegv(usig);
}
@@ -2347,8 +2414,10 @@ static void setup_rt_frame_v1(int usig, struct target_sigaction *ka,
__put_user(set->sig[i], &frame->uc.tuc_sigmask.sig[i]);
}
- setup_return(env, ka, &frame->retcode, frame_addr, usig,
- frame_addr + offsetof(struct rt_sigframe_v1, retcode));
+ if (setup_return(env, ka, frame->retcode, frame_addr, usig,
+ frame_addr + offsetof(struct rt_sigframe_v1, retcode))) {
+ goto sigsegv;
+ }
env->regs[1] = info_addr;
env->regs[2] = uc_addr;
@@ -2356,6 +2425,7 @@ static void setup_rt_frame_v1(int usig, struct target_sigaction *ka,
unlock_user_struct(frame, frame_addr, 1);
return;
sigsegv:
+ unlock_user_struct(frame, frame_addr, 1);
force_sigsegv(usig);
}
@@ -2378,8 +2448,10 @@ static void setup_rt_frame_v2(int usig, struct target_sigaction *ka,
setup_sigframe_v2(&frame->uc, set, env);
- setup_return(env, ka, &frame->retcode, frame_addr, usig,
- frame_addr + offsetof(struct rt_sigframe_v2, retcode));
+ if (setup_return(env, ka, frame->retcode, frame_addr, usig,
+ frame_addr + offsetof(struct rt_sigframe_v2, retcode))) {
+ goto sigsegv;
+ }
env->regs[1] = info_addr;
env->regs[2] = uc_addr;
@@ -2387,6 +2459,7 @@ static void setup_rt_frame_v2(int usig, struct target_sigaction *ka,
unlock_user_struct(frame, frame_addr, 1);
return;
sigsegv:
+ unlock_user_struct(frame, frame_addr, 1);
force_sigsegv(usig);
}
--
2.6.3
© 2016 - 2024 Red Hat, Inc.