Re: AUTIA authentication sometimes fails

[Richard Henderson]

On 3/29/21 3:04 PM, Peter Maydell wrote:
> On Mon, 29 Mar 2021 at 21:07, Derrick McKee <derrick.mckee@gmail.com> wrote:
> > Hi,
> >
> > I am running across a scenario where a PAC signed code pointer (using
> > pacia) sometimes does not successfully authenticate despite the signed
> > pointer and the salt used to sign the pointer are correctly given to a
> > autia instruction.  Only one particular pointer fails, while others
> > are correctly authenticated.  Unfortunately, I can't provide a simple
> > use case, because the behavior is part of a running kernel, and all
> > the pointers involved are kernel space pointers.  An example of what I
> > am seeing (not guaranteeing correct assembly, just a gist):
> >
> > mov x9, 0xffff800009200000
> > mov x10, 0x20001
> > pacia x9, x10  // x9 contains 0xff90800009200000
> > ...
> > mov x9, 0xff90800009200000
> > mov x10 0x20001
> > autia x9, x10  // x9 contains invalid pointer
> >
> > However, this same code with different pointer values correctly
> > authenticate.  Is there something specific about the kernel and PAC
> > authentication that I am missing?  Thanks.
>
> cc'ing Richard, but I suspect you'll need to provide more detail...

Definitely.

I transliterated your code above into a stand-alone test case:

#include <assert.h>
#include <stdio.h>

int main()
{
    unsigned long p0 = 0xffff800009200000ul;
    unsigned long salt = 0x20001;
    unsigned long p1, p2;

    asm("pacia %0, %1" : "=r"(p1) : "r"(salt), "0"(p0));
    asm("autia %0, %1" : "=r"(p2) : "r"(salt), "0"(p1));
    assert(p2 == p0);

    printf("%016lx\n%016lx\n", p0, p1);
    return 0;
}

In your comments above, 0xff90800009200000 is the signed pointer, with the top 
16 bits (ff90) bearing the signature.  This exact value cannot be obtained 
without knowing the contents of the encryption key and will of course vary from 
run to run.

The test case above does not fail.

So: more details about the context are required.

I must say that my first guess is that you're signing with one encryption key 
and authenticating with a different encryption key, with the kernel having 
performed a context switch in the interim.


r~