From: Peter Maydell <peter.maydell@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH 2/4] target/arm: Update MSR access to UAO
Date: Sun, 2 Feb 2020 13:29:59 +0000 [thread overview]
Message-ID: <CAFEAcA8tkhpHAM2niDmpm=Oi4XQDTNTzKUJ_A-hKFLXsz_rPxw@mail.gmail.com> (raw)
In-Reply-To: <2871294a-0577-9390-1887-a2e81c1a35e6@linaro.org>
On Sun, 2 Feb 2020 at 01:00, Richard Henderson
<richard.henderson@linaro.org> 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
next prev parent reply other threads:[~2020-02-02 13:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 23:42 [PATCH 0/4] target/arm: Implement ARMv8.2-UAO Richard Henderson
2019-12-03 23:42 ` [PATCH 1/4] target/arm: Add ID_AA64MMFR2_EL1 Richard Henderson
2019-12-06 18:19 ` Peter Maydell
2020-02-02 0:54 ` Richard Henderson
2019-12-03 23:42 ` [PATCH 2/4] target/arm: Update MSR access to UAO Richard Henderson
2019-12-06 18:30 ` Peter Maydell
2019-12-06 19:00 ` Richard Henderson
2020-02-02 1:00 ` Richard Henderson
2020-02-02 13:29 ` Peter Maydell [this message]
2020-02-03 7:46 ` Richard Henderson
2019-12-03 23:42 ` [PATCH 3/4] target/arm: Implement UAO semantics Richard Henderson
2019-12-06 18:31 ` Peter Maydell
2019-12-03 23:42 ` [PATCH 4/4] target/arm: Enable ARMv8.2-UAO in -cpu max Richard Henderson
2019-12-06 18:31 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFEAcA8tkhpHAM2niDmpm=Oi4XQDTNTzKUJ_A-hKFLXsz_rPxw@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.