Re: [PATCH 2/4] target/arm: Update MSR access to UAO

[Peter Maydell]

On Sun, 2 Feb 2020 at 01:00, Richard Henderson
<address@hidden> wrote:
> > Does the "on exception entry PSTATE.UAO is zeroed" behaviour
> > fall out automatically for us?
>
> Yes, aarch64_pstate_mode() returns a clean PSTATE.
>
> > How about "on exception entry
> > from aarch32 to aarch64 SPSR_ELx.UAO is set to zero" ?
>
> This follows the same path as above, as far as I can see.

Yes, but SPSR_ELx isn't started with a clean zero and built up
the way the new PSTATE is, it gets copied from the AArch32 CPSR
via cpsr_read(). I forget how carefully we keep the guest from setting
CPSR bits that aren't really valid for the CPU...

> > I think we may also want a minor code change so that an exception
> > return from aarch64 to aarch32 doesn't copy a bogus SPSR UAO==1
> > into the pstate/cpsr.
>
> Well, there is no CPSR UAO bit, so there's no aarch32 bit to clear.  But I did
> add a clearing of PSTATE UAO on the exception return to aarch64 path, to
> prevent the guest from playing games with SPSR.

...for instance on the aarch64->aarch32 exception return path,
I don't think we sanitize the SPSR bits, so the guest could use
a 64->32 exception return to set a bogus CPSR.UAO bit and
then enter from 32 to 64 and see SPSR_ELx.UAO set when
it should not be, unless we sanitize either in all places where
we let the guest set CPSR bits (including 64->32 return), or
we sanitize on 32->64 entry.

thanks
-- PMM