[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Differing PAC behavior between Qemu and Arm FVP

From: Derrick McKee
Subject: Re: Differing PAC behavior between Qemu and Arm FVP
Date: Tue, 28 Jul 2020 13:10:05 -0400

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.

On Tue, Jul 28, 2020 at 11:50 AM Richard Henderson <richard.henderson@linaro.org> wrote:
> 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.


Derrick McKee
Phone: (703) 957-9362
Email: derrick.mckee@gmail.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]