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~
