[PATCH 1/2] ARM: BUG if jumping to usermode address in kernel mode

[Peter Maydell]

On 27 November 2017 at 11:47, Russell King - ARM Linux
<linux at armlinux.org.uk> wrote:
> On Mon, Nov 27, 2017 at 11:16:06AM +0100, Cédric Le Goater wrote:
>> Additional QEMU logging gives us :
>>
>>   Ignoring attempt to switch CPSR_A flag from non-secure world with SCR.AW bit clear
>>   Ignoring attempt to switch CPSR_F flag from non-secure world with SCR.FW bit clear

> From what it sounds like, when you run the kernel without uboot, QEMU
> decides to run the kernel in the nonsecure world.  If it did the same
> with u-boot, u-boot would not be able to change the SCR register, so
> u-boot must run in the secure world if it's setting the AW and FW
> bits.

Yes, this seems like a QEMU bug. (Added qemu-devel to cc: accordingly).
We'll print this warning for a v7 CPU which has the Security Extensions
but not the Virtualization Extensions (which is the case where the
architecture mandates that NS not be able to change the CPSR.A and
F bits), but we shouldn't (in theory) get into that situation
because either:
 * we started the emulation by running a secure bootrom, which
   should have initialized SCR.AW/FW correctly before booting the
   NS kernel (I assume this is the "run from u-boot" setup)
 * we started the kernel directly from QEMU, in which case QEMU's
   internal "act like a bootloader" code should have done the
   setting of SCR.AW/FW.

Cedric's command line is the second of these types, so something's
gone wrong in our internal bootloader. The code in
hw/arm/boot.c:arm_write_secure_board_setup_dummy_smc() sets up
a little bit of guest code that runs in secure mode and sets
SCR.AW/FW. I suspect the romulus-bmc machine model isn't invoking
that code.

Most QEMU users shouldn't be affected by this because not
many board models default to enabling the security extensions
in the emulated CPU, and the highbank and raspi boards at least
do do this secure-mode setup I think.

thanks
-- PMM