Clarify authorisation of PREFETCH.I in integer mode

[tariqkurd-repo]

Clarify authorisaton of prefetch.i in integer mode

[arichardson]

Jumps are definitely authorized by PCC and I thought prefetch was as well? I don't recall changing that

[jrtc27]

How is this "out of date"? This is the place that defines that behaviour!

[tariqkurd-repo]

This is hybrid mode text - but in any case jump and branch targets are no longer authorised by PCC - because we removed all of the target exception checks - the only thing which can happen now is detagging the target PCC if the target is unrepresentable - there's no actual authorisation against PCC.

For prefetch.i maybe things aren't quite so clear - but - using PCC bounds to authorise the prefetch isn't implementable - as in a high performance architecture with PCC prediction there may be many sets of PCC bounds in flight at once. As it's a prefetch this leaves us with a few options:

1. make the rule into a recommendation
2. delete the authorisation clause - as PREFETCH.I is indistinguishable from a hardware prefetcher
3. use DDC bounds - as PREFETCH.I is likely to execute in the LSU

...but as it stands, requiring accurately authorising PREFETCH.I with PCC bounds forces only having one set of PCC bounds in flight and so disables PCC prediction, or just makes PREFETCH.I execute as NOP as the authority can't be checked in a sensible way.

[jrtc27]

It’s authorised by PCC in the same way that capability mode AUIPC reads PCC. If you’re speculating on PCC then that’s what you use. Though you want to be careful about speculative execution attacks…

Also, can we please stop changing the spec in substantive ways? Maybe the branch one is a clarification and nothing more, but PREFETCH.I is not. The spec is supposed to be frozen for ARC review.

[tariqkurd-repo]

It’s authorised by PCC in the same way that capability mode AUIPC reads PCC. If you’re speculating on PCC then that’s what you use. Though you want to be careful about speculative execution attacks…

Also, can we please stop changing the spec in substantive ways? Maybe the branch one is a clarification and nothing more, but PREFETCH.I is not. The spec is supposed to be frozen for ARC review.

The idea isn't to change the spec for any purpose but fixing bugs. My intention in the past had been to remove PCC from prefetch.i checks I had obviously failed to do so as that clause remained in the Zyhybrid chapter.

I'll make a separate PR for removing PCC for authorising branches, as that part isn't contentious (#902)

We can have a separate discussion about a more implementable spec for prefetch.i, right now it's not very implementable.

[nwf]

In at least some proposed uses of hybrid mode, PCC and DDC are not "infinite" capabilities and are likely to be disjoint, so I'd think anything that looks like "instruction address" should be considered PCC-authorized.

[tariqkurd-repo]

In at least some proposed uses of hybrid mode, PCC and DDC are not "infinite" capabilities and are likely to be disjoint, so I'd think anything that looks like "instruction address" should be considered PCC-authorized.

Yes - I agree - and for something like AUIPC[C] then clearly PCC needs to be used - as Jess said above.

Prefetches are hints though and for prefetch.i in integer mode only, which is quite niche, it's not worth wiring up access to the speculative PCC to every load unit in a high performance implementation.

Therefore my proposal is to change it to a recommendation that PCC is used for authorisation, but not a normative rule, so a simpler implementation can certainly keep the authorisation, but a more complex one which doesn't have PCC available in the correct place can choose not to. Even with the normative rule in place you can't prove the behaviour due to hardware prefetchers potentially fetching the same line.

[davidchisnall]

I agree, an implementation that decides to deliberately introduce attack vectors for side channel attacks should be free to do so, just as it is with the cache flush instructions.

[tariqkurd-repo]

I agree, an implementation that decides to deliberately introduce attack vectors for side channel attacks should be free to do so, just as it is with the cache flush instructions.

Yes - it becomes an implementation choice - not an architectural requirement.
There are many tradeoffs between resiliance to side channel attacks and performance in high performance designs, this is another to add to the list.

[arichardson]

I think this needs a note that using DDC instead of PCC only affects hybrid mode and side-channels, therefore use DDC is fine.