Instruction page fault for an illegal target address of Sv39 from a taken branch

[chuanhua.chang]

In section 4.4.1 (page 64) of the latest privileged spec (for Sv39), it says that
------------
Instruction fetch addresses and load and store effective addresses, which are 64 bits, must have bits 63–39 all equal to bit 38, or else a page-fault exception will occur.
------------

In section 2.2 (page 11) of the latest ISA spec, it says that
----------
An instruction address misaligned exception is generated on a taken branch or unconditional jump if the target address is not four-byte aligned.
----------

So a misaligned address from a taken branch will generate the instruction misaligned exception at the branch instruction, while an illegal address of Sv39 from a taken branch will generate the instruction page fault exception at the target fetch address (i.e., next instruction) during instruction fetch?

Or an illegal address of Sv39 from a taken branch will generate the instruction page fault exception at the branch instruction?

Clarification of this behavior is needed. Thanks.

Chuanhua

[Tommy Thorn]

The way I read it, it's the former interpretation, which nicely resolves the ambiguity that

would otherwise happen if you branched to a misaligned *and* wrongly sign-extended

address.

Kindly check if the riscv-test doesn't cover these cases yet (including the two-faults-in-

one I mentioned) and file an issue if they don't.

Tommy

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/e5925939-ae9c-419e-9dbd-502135fd150f%40groups.riscv.org.

[Andrew Waterman]

On Wed, May 16, 2018 at 12:24 AM Tommy Thorn <tommy...@esperantotech.com> wrote:

The way I read it, it's the former interpretation, which nicely resolves the ambiguity that

would otherwise happen if you branched to a misaligned *and* wrongly sign-extended

address.

Right.

Kindly check if the riscv-test doesn't cover these cases yet (including the two-faults-in-

one I mentioned) and file an issue if they don't.

Better yet, write a test.

Tommy

On Wed, May 16, 2018 at 12:13 AM, chuanhua.chang <chuanhu...@gmail.com> wrote:

In section 4.4.1 (page 64) of the latest privileged spec (for Sv39), it says that
------------
Instruction fetch addresses and load and store effective addresses, which are 64 bits, must have bits 63–39 all equal to bit 38, or else a page-fault exception will occur.
------------

In section 2.2 (page 11) of the latest ISA spec, it says that
----------
An instruction address misaligned exception is generated on a taken branch or unconditional jump if the target address is not four-byte aligned.
----------

So a misaligned address from a taken branch will generate the instruction misaligned exception at the branch instruction, while an illegal address of Sv39 from a taken branch will generate the instruction page fault exception at the target fetch address (i.e., next instruction) during instruction fetch?

Or an illegal address of Sv39 from a taken branch will generate the instruction page fault exception at the branch instruction?

Clarification of this behavior is needed. Thanks.

Chuanhua

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/e5925939-ae9c-419e-9dbd-502135fd150f%40groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPZiS_6V8V6VdHWm5vn_TNWHyiAgQygpq5vB_kuxbmXuJqZpvg%40mail.gmail.com.

[chuanhua.chang]

But how about the original intention/principle of detecting an ill-formed target address at the source instruction instead of the target instruction for easy debugging? I thought Krste once mentioned that detecting misaligned target address at the branch instruction is a good definition for this.

Then why favor the misaligned address, but not favor the illegal Sv39 address? To resolve the two simultaneous exceptions on the same branch instruction, we just need a priority order definition for these two exceptions.

Chuanhua

[Andrew Waterman]

On Thu, May 17, 2018 at 9:04 AM, chuanhua.chang <chuanhu...@gmail.com> wrote:

But how about the original intention/principle of detecting an ill-formed target address at the source instruction instead of the target instruction for easy debugging? I thought Krste once mentioned that detecting misaligned target address at the branch instruction is a good definition for this.

Then why favor the misaligned address, but not favor the illegal Sv39 address? To resolve the two simultaneous exceptions on the same branch instruction, we just need a priority order definition for these two exceptions.

Yeah, the goal is to detect exceptions as early as is convenient.  It's easy to detect misalignment when the branch executes.  It's harder to detect whether a virtual address is valid when a branch executes, because it would impose a structural hazard on the ITLB, especially if instruction fetch is decoupled.

IMO, this ISA design choice is somewhat inconsistent but is also pragmatic.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/41f01e55-c1cb-4382-b779-03b4fa9df689%40groups.riscv.org.

[Jacob Bachmeyer]

Andrew Waterman wrote:
> On Thu, May 17, 2018 at 9:04 AM, chuanhua.chang
> <chuanhu...@gmail.com <mailto:chuanhu...@gmail.com>> wrote:
>
> But how about the original intention/principle of detecting an
> ill-formed target address at the source instruction instead of the
> target instruction for easy debugging? I thought Krste once
> mentioned that detecting misaligned target address at the branch
> instruction is a good definition for this.
>
> Then why favor the misaligned address, but not favor the illegal
> Sv39 address? To resolve the two simultaneous exceptions on the
> same branch instruction, we just need a priority order definition
> for these two exceptions.
>
>
> Yeah, the goal is to detect exceptions as early as is convenient.
> It's easy to detect misalignment when the branch executes. It's
> harder to detect whether a virtual address is valid when a branch
> executes, because it would impose a structural hazard on the ITLB,
> especially if instruction fetch is decoupled.
>
> IMO, this ISA design choice is somewhat inconsistent but is also
> pragmatic.

It should also be worth noting that "instruction misaligned",
"instruction access fault", and "instruction page fault" are all
distinct exceptions in RISC-V.

This choice to take instruction fetch exceptions due to invalid
instruction addresses at the instruction fetch and not at the
instruction that placed the invalid value in pc also has security
implications with xRET: AMD64 defines similar handling of
return-from-syscall-to-bogus-address and works correctly; while Intel
decided that Intel EM64T would check that the destination address is
canonical and raise a fault if not. The end result was the infamous
"Intel SYSRET bug":
<URL:https://bugzilla.redhat.com/show_bug.cgi?id=813428>,
<URL:https://blog.xenproject.org/2012/06/13/the-intel-sysret-privilege-escalation/>,
<URL:https://wiki.osdev.org/Sysenter>

Taking the fault on instruction fetch *after* the control transfer has
retired is probably the only safe option here.


-- Jacob