From: Chris Williams <diodesign@tuta.io>
To: Alistair Francis <alistair23@gmail.com>
Cc: Palmer Dabbelt <palmer@sifive.com>,
Alistair Francis <alistair.francis@wdc.com>,
Sagar Karandikar <sagark@eecs.berkeley.edu>,
Bastian Koppelmann <kbastian@mail.uni-paderborn.de>,
Qemu Riscv <qemu-riscv@nongnu.org>,
Qemu Devel <qemu-devel@nongnu.org>, <dayeol@berkeley.edu>
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.
WARNING: multiple messages have this Message-ID (diff)
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.
next prev parent reply other threads:[~2019-10-15 18:02 UTC|newest]
Thread overview: 7+ 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 22:18 ` Alistair Francis
2019-10-11 23:17 ` Dayeol Lee
2019-10-11 23:17 ` Dayeol Lee
2019-10-15 18:02 ` Chris Williams [this message]
2019-10-15 18:02 ` Chris Williams
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 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.