[Top][All Lists]

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

[PATCH 0/7] Allow semihosting from user mode

From: Peter Maydell
Subject: [PATCH 0/7] Allow semihosting from user mode
Date: Mon, 15 Aug 2022 20:02:56 +0100

Currently our semihosting implementations usually prohibit use of
semihosting calls in system emulation from the guest userspace.  This
is a very long standing behaviour justified originally "to provide
some semblance of security" (since code with access to the semihosting
ABI can do things like read and write arbitrary files on the host
system).  However, it is sometimes useful to be able to run trusted
guest code which performs semihosting calls from guest userspace,
notably for test code.

This patchset adds a command line suboption to the existing
semihosting-config option group so that you can explicitly opt in to
semihosting from guest userspace with "-semihosting-config

It also brings all our target architectures into line about
how they handle semihosting. Currently these fall into three
different groups:

 * semihosting permitted only in privileged mode and only
   if enabled on the command line:
   - arm
   - m68k
 * semihosting permitted in any mode, if enabled on the command line:
   - mips
   - nios2
   - xtensa
 * semihosting permitted only in privileged mode, but fails
   to honour the existing "enable semihosting" option, instead
   enabling it all the time:
   - riscv

The effect of the new option for group 1 is:
 * user can now optionally also allow semihosting in usermode

For group 2 it is:
 * usermode semihosting used to be permitted, but now changes
   to default-disabled, needing explicit enablement

For group 3 it is:
 * semihosting overall used to be default-enabled and is
   now default-disabled, needing explicit enablement.
   Semihosting in usermode can also be enabled.

That means this is a "things that used to work no longer do
unless you change your commandline" change for groups 2 and 3
(so, mips, nios2. xtensa, riscv). In this patchset I've opted
to just make the change (with the intention of releasenoting
it) but I'm open to arguments that we ought to put it through
the deprecate-and-delete cycle. (I suspect this probably most
affects riscv.)

The patchset structure adds the option first and then updates
each target architecture in turn to honour it. It didn't seem
to me worth the extra patch-splitting to put the underlying
infrastructure in first, then the target changes and finally
exposing the option to the user only once it's honoured

NB: I haven't really tested this much, just 'make check'
and 'make check-avocado'; I wanted to get it out to the
mailing list for discussion, anyway.

-- PMM

Peter Maydell (7):
  semihosting: Allow optional use of semihosting from userspace
  target/arm: Honour -semihosting-config userspace=on
  target/m68k: Honour -semihosting-config userspace=on
  target/mips: Honour -semihosting-config userspace=on
  target/nios2: Honour -semihosting-config userspace=on
  target/xtensa: Honour -semihosting-config userspace=on
  target/riscv: Honour -semihosting-config userspace=on and enable=on

 include/semihosting/semihost.h            | 10 ++++++++--
 semihosting/config.c                      | 10 ++++++++--
 softmmu/vl.c                              |  2 +-
 stubs/semihost.c                          |  2 +-
 target/arm/translate-a64.c                | 12 +-----------
 target/arm/translate.c                    | 16 ++++------------
 target/m68k/op_helper.c                   |  3 +--
 target/mips/tcg/translate.c               |  9 +++++----
 target/nios2/translate.c                  |  3 ++-
 target/riscv/cpu_helper.c                 |  3 ++-
 target/xtensa/translate.c                 |  7 ++++---
 target/mips/tcg/micromips_translate.c.inc |  6 +++---
 target/mips/tcg/mips16e_translate.c.inc   |  2 +-
 target/mips/tcg/nanomips_translate.c.inc  |  4 ++--
 qemu-options.hx                           | 11 +++++++++--
 15 files changed, 52 insertions(+), 48 deletions(-)


reply via email to

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