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

[Richard Henderson]

On 2/2/20 1:29 PM, Peter Maydell wrote:
> 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...

We do an ok job, except...

>> 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,

... here.

> 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.

There is no CPSR.UAO bit, so this chain of logic doesn't hold for that specific
instance.  But plausibly so for CPSR.PAN.

We do sanitize all of the places where CPSR/PSTATE is explicitly set.  I think
we've covered all but one of the exception return paths, sanitizing the
SPSR_ELx values.

We could move some of this logic to internals.h so that it could be shared
between CPSR and exception return.  I'll think about that for v3.


r~