blob: bdf43bbc598feb25714a11e281a05a4cfdf22422 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
ARM v8.3a pauth not working
Host: Ubuntu 19.10 - x86_64 machine
QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master)
ARMV8.3 pauth is not working well.
With a test code containing two pauth instructions:
- paciasp that sign LR with A key and sp as context;
- autiasp that verify the signature.
Test:
- Run the program and corrupt LR just before autiasp (ex 0x3e00000400660 instead of 0x3e000000400664)
Expected:
- autiasp places an invalid pointer in LR
Result:
- autiasp successfully auth the pointer and places 0x0400660 in LR.
Further explanations:
Adding traces in qemu code shows that "pauth_computepac" is not robust enough against truncating.
With 0x31000000400664 as input of pauth_auth, we obtain "0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
With 0x310040008743ec as input of pauth (with same key), we obtain "0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
Values of top_bit and bottom_bit are strictly the same and it should not.
Hi,
Here is a patch for this bug. The sbox function was using "b+=16" instead of "b+=4".
Also, you check test vector using :
```c
uint64_t P = 0xfb623599da6e8127ull;
uint64_t T = 0x477d469dec0b8762ull;
uint64_t w0 = 0x84be85ce9804e94bull;
uint64_t k0 = 0xec2802d4e0a488e9ull;
ARMPACKey key = { .hi = w0, .lo = k0 };
uint64_t C5 = pauth_computepac(P, T, key);
/* C5 should be 0xc003b93999b33765 */
```
Ooof. Good catch on the sbox error.
That said, how did you test pauth_computepac?
I still do not get the C5 result above, but 0x99d88f4472f3be39.
The following test case sets up the parameters.
Oops again. The test case has the parts of the key the wrong way around.
I'll submit the pair of patches to the mailing list.
Now upstream as commit de0b1bae6461f67243282555475f88b2384a1eb9.
Apparently this fixed bug is the official CVE-2020-10702:
https://security-tracker.debian.org/tracker/CVE-2020-10702
|