From: Chris Williams <diodesign@tuta.io>
To: Alistair Francis <alistair23@gmail.com>
Cc: Qemu Riscv <qemu-riscv@nongnu.org>,
Sagar Karandikar <sagark@eecs.berkeley.edu>,
dayeol@berkeley.edu,
Bastian Koppelmann <kbastian@mail.uni-paderborn.de>,
Palmer Dabbelt <palmer@sifive.com>,
Qemu Devel <qemu-devel@nongnu.org>,
Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [PATCH v2 1/1] target/riscv/pmp: Fix bug preventing
Date: Tue, 15 Oct 2019 20:02:45 +0200 (CEST) [thread overview]
Message-ID: <LrF_XLH--3-1@tuta.io> (raw)
In-Reply-To: <CAKmqyKNh-jgg-LWHp4RMM9vaaMNr7qHtNSVYs9OFXhvJ-+7RXA@mail.gmail.com>
Hi,
Oct 11, 2019, 15:18 by alistair23@gmail.com:
> On Sun, Oct 6, 2019 at 1:32 AM Chris Williams <diodesign@tuta.io> wrote:
>
> Also please use `git format-patch` to format the patch and then `git
> send-email` to send the patch. There is a whole heap of detail here:
> https://wiki.qemu.org/Contribute/SubmitAPatch <https://wiki.qemu.org/Contribute/SubmitAPatch>
>
OK, I will do in future. I read the page but failed to get it right. Thanks for spotting my patch, and the advice, though.
>> This fixes an issue that prevents a RISC-V CPU from executing instructions
>> immediately from the base address of a PMP TOR region.
>>
>> When jumping to an instruction in a PMP TOR region, pmp_hart_has_privs() is
>> called to validate the access. If this instruction is the very first word of a
>> PMP TOR region, at address 0 relative to the start address of the region, then
>> the access will fail. This is because pmp_hart_has_privs() is called with size
>> 0 to perform this validation, causing this check...
>>
>> e = pmp_is_in_range(env, i, addr + size - 1);
>>
>> ... to fail, as (addr + size - 1) falls below the base address of the PMP
>> region. Really, the access should succeed. For example, if I have a region
>> spanning 0x80d96000 to 0x88d95fff and the CPU jumps to 0x80d96000, then:
>>
>> s = 0x80d96000
>> e = 0x80d95fff
>>
>> And the validation fails. The size check proposed below catches these zero-size
>> instruction fetch access probes. The word alignment in pmpaddr{0-15} and
>> earlier instruction alignment checks should prevent the execution of
>> instructions over the upper boundary of the PMP region, though I'm happy to give
>> this more attention if this is a concern.
>>
>
> This seems like a similar issue to this patch as well:
> https://lore.kernel.org/qemu-devel/20191007052813.25814-1-dayeol@berkeley.edu/ <https://lore.kernel.org/qemu-devel/20191007052813.25814-1-dayeol@berkeley.edu/>
>
Yes, it appears Dayeol and I have encountered the same issue.
> From that discussion:
>
> "In general, size 0 means "unknown size". In this case, the one tlb lookup is
> going to be used by lots of instructions -- everything that fits on the page."
>
> Richard's last comment seems like a better fix:
>
> "You certainly could do
>
> if (size == 0) {
> size = -(addr | TARGET_PAGE_MASK);
> }
>
> to assume that all bytes from addr to the end of the page are accessed. That
> would avoid changing too much of the rest of the logic.
>
> That said, this code will continue to not work for mis-aligned boundaries."
>
> So I don't think this is the correct solution. I'm not sure if Dayeol
> is planning on sending a follow up version. If not feel free to send
> it.
>
I'm happy for Dayeol to submit a better patch, if necessary.
>> Signed-off-by: Chris Williams <diodesign@tuta.io <mailto:diodesign@tuta.io>>
>>
>
> It looks like this is a HTML patch, also ensure all patches are just
> plain text, `git send-email` will do this.
>
Yes, you're right: my webmail client isn't particularly neighborly with respect to Qemu's submission process.
C.
prev parent reply other threads:[~2019-10-15 18:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-06 8:32 [PATCH v2 1/1] target/riscv/pmp: Fix bug preventing Chris Williams
2019-10-11 22:18 ` Alistair Francis
2019-10-11 23:17 ` Dayeol Lee
2019-10-15 18:02 ` Chris Williams [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=LrF_XLH--3-1@tuta.io \
--to=diodesign@tuta.io \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=dayeol@berkeley.edu \
--cc=kbastian@mail.uni-paderborn.de \
--cc=palmer@sifive.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=sagark@eecs.berkeley.edu \
/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).