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