qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.


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