I'm not quite sure if it matters, but I am also using MTE as well. My understanding is that the only affect to PAC is that the available signature bits are reduced But I am definitely getting a valid pointer from the second pacda instruction because the autda instruction succeeds. My application is kinda convoluted because I was testing out a research idea. I'll try to come up with a minimal test case, and test it out on the Qemu master head.
> The scenario: Application signs pointer 0xdeadbeef using the pacda
> instruction to obtain a new pointer 0xXYdeadbeef. Later, the application
> wants to generate a new PAC signature for 0xdeadbeef, but uses 0xXYdeadbeef
> as the address for the pacda instruction to generate pointer 0xABdeadbeef.
> Finally, the application wants to authenticate using the autda instruction
> using 0xABdeadbeef and the modifier used to generate that pointer.>
> Qemu behavior: The autda instruction succeeds and 0xdeadbeef is returned.
>
> FVP behavior: The autda instruction fails, and an invalid pointer is
> returned. In order for the autda instruction to succeed, the pointer
> provided to the pacda instruction must have the upper bits set to zero.
>
> Is this a bug, or are we not very concerned about corner cases like these?
Well, actually, if you haven't already gotten an invalid pointer out of step
two (the second pacda) then *that* is a bug. And an invalid pointer should not
succeed the autda.
So, yes, this does sound like a bug.
I will see if I can create a test case for this, but if you already have one,
that would also be helpful.
r~