From: Peter Maydell <peter.maydell@linaro.org>
To: Wei Huang <wei@redhat.com>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>,
Igor Mammedov <imammedo@redhat.com>,
Shannon Zhao <zhaoshenglong@huawei.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Shannon Zhao <shannon.zhao@linaro.org>
Subject: Re: [Qemu-trivial] [PATCH V2 1/2] ARM: PL061: Clear PL061 device state after reset
Date: Wed, 17 Feb 2016 19:23:55 +0000 [thread overview]
Message-ID: <CAFEAcA9LuN6--czsaU72VCqacgbvd2DM1Ka9A-c5k_a0FozbhQ@mail.gmail.com> (raw)
In-Reply-To: <56C4C55F.2050006@redhat.com>
On 17 February 2016 at 19:09, Wei Huang <wei@redhat.com> wrote:
>
>
> On 02/17/2016 11:53 AM, Peter Maydell wrote:
>> On 17 February 2016 at 17:34, Wei Huang <wei@redhat.com> wrote:
>>> On 02/16/2016 08:39 AM, Peter Maydell wrote:
>>>> Side note: half our "PL061" behaviour is actually specific
>>>> to the TI variant in the Luminary, and for our plain old PL061
>>>> we ought to restrict access to the registers that are Stellaris
>>>> only. But that's a different bug and not a very major one.
>>>
>>> Thanks for your suggestion. I was trying to fix it. The plan was to add
>>> a new field rsvd_addr in "struct PL061State". Then in pl061_read() and
>>> pl061_write(), we can check offset against [rsvd_addr, 0xfcc] (ignored
>>> if inside).
>>>
>>> While I was working on it, I realized that this is a benign issue. It is
>>> true that PL061 device can access Luminary registers in the reserved
>>> memory area. However QEMU doesn't use these Luminary registers anywhere
>>> else other than pl061_read() and pl061_write(). It basically passes the
>>> read/write requests through. I don't see a malicious driver can damage
>>> device state. Thoughts?
>>
>> It's not a "malicious guest can do bad things" bug, it's a "modelled
>> hardware doesn't behave like the real thing" bug. A non-Luminary PL061
>> should act like the hardware, which means that the registers that don't
>> exist should be RAZ/WI (and should log guest-errors if the guest tries
>> to access them), the same way we do in the "default" case of the
>> case statements for other reserved registers.
>
> How about the attached patch? I can write a new patch based on it, or
> you prefer stashing it on top of V3 I just submitted?
Looks OK, but you don't need to check for address being <= 0xfcc
because either we've already handled the ID registers (read)
or we were going to be reserved anyway (write).
thanks
-- PMM
prev parent reply other threads:[~2016-02-17 19:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 20:49 [Qemu-trivial] [PATCH V2 1/2] ARM: PL061: Clear PL061 device state after reset Wei Huang
2016-02-01 20:49 ` [Qemu-trivial] [PATCH V2 2/2] ARM: PL061: Cleaning field of PL061 device state Wei Huang
2016-02-16 14:36 ` Peter Maydell
2016-02-03 12:46 ` [Qemu-trivial] [PATCH V2 1/2] ARM: PL061: Clear PL061 device state after reset Shannon Zhao
2016-02-16 14:35 ` Peter Maydell
2016-02-16 14:39 ` Peter Maydell
2016-02-17 17:34 ` Wei Huang
2016-02-17 17:53 ` Peter Maydell
2016-02-17 19:09 ` Wei Huang
2016-02-17 19:23 ` Peter Maydell [this message]
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=CAFEAcA9LuN6--czsaU72VCqacgbvd2DM1Ka9A-c5k_a0FozbhQ@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=imammedo@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=shannon.zhao@linaro.org \
--cc=wei@redhat.com \
--cc=zhaoshenglong@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).