Open nwf opened 2 years ago
So from stval
it is a cause of 1 (length violation) and register index of 12 (c12 / ca2).
I think the reason is that you can't seal a sentry cap with CSeal
but instead need to use CSealEntry
as the otype
for a sentry exceeds cap_max_otype
.
OK, after #1406 is applied, we're left with a pretty clearly a case of corruption leading to us attempting to reconstruct a capability we shouldn't be reconstructing. I've rebuilt my kernel in the interim (sorry), so the code leading up to the panic is now
ffffffc0005ae6bc: 0f a6 0a ff lc ca2, -16(s5)
; base = cheri_getbase(cap);
ffffffc0005ae6c0: db 08 26 fe cgetbase a7, ca2
; len = cheri_getlen(cap);
ffffffc0005ae6c4: db 02 36 fe cgetlen t0, ca2
; newcap = swap_restore_cap;
ffffffc0005ae6c8: 0f 28 09 00 lc ca6, 0(s2)
; offset = cheri_getoffset(cap);
ffffffc0005ae6cc: db 07 66 fe cgetoffset a5, ca2
; perm = cheri_getperm(cap);
ffffffc0005ae6d0: db 06 06 fe cgetperm a3, ca2
; sealed = cheri_getsealed(cap);
ffffffc0005ae6d4: 5b 07 56 fe cgetsealed a4, ca2
; newcap = cheri_setoffset(newcap, base);
ffffffc0005ae6d8: db 05 18 1f csetoffset ca1, ca6, a7
; newcap = cheri_setbounds(newcap, len);
ffffffc0005ae6dc: db 85 55 10 csetbounds ca1, ca1, t0
and the register dump says
s[5] = 0xffffffd03901f400
a[1] = 0x5700000000000000 [rwxRW,0x0000000000000000-0xffffffffffffffff]
a[2] = 0x2800363332002074 [W,0x5700000000000000-0x56ffffffffffffff] (invalid,sealed)
a[3] = 0x0000000000018220
a[4] = 0x0000000000000001
a[5] = 0xd100363332002074
a[6] = 0x0000000000000000 [rwxRW,0x0000000000000000-0xffffffffffffffff]
a[7] = 0x5700000000000000
t[0] = 0xffffffffffffffff
and ddb
can give us the raw memory around s5
:
db> x/x 0xffffffd03901f3e0,16
0xffffffd03901f3e0: 69766168 a72756f 49000a00 7265736e
0xffffffd03901f3f0: 32002074 28003633 20746572 32203d3d
0xffffffd03901f400: 7c7c2029 74702820 3d3d2072 69726f20
0xffffffd03901f410: 46002967 656c6961 6f742064 74656720
0xffffffd03901f420: 73797320 206d6574 646e6172 656e6d6f
0xffffffd03901f430: 46007373 656c6961
Unfortunately for us, the "capability" in question is at 0xffffffd03901f3f0
, which, if we ask ddb
a little differently...
db> x/bc 0xffffffd03901f3f0,16
0xffffffd03901f3f0: t \000236\000(ret == 2) || (
is almost surely not meant to be a capability.
I think #1406 should land as it clearly is a fix, but it's not the fix.
I wonder if it would be worth taking the time to add an HMAC for swapped pages. It's something we likely want anyway in a production CHERI system.
Here's a panic in
swp_pager_async_iodone
; the fault address,0xffffffc0005ac242
, is thecseal ca1, ca1, ca2
instruction therein.This is
which is really 6533f358f80aa8dbde80b13851210d4082911a3c with unrelated (I hope) changes atop it. Running in
qemu
using the default disk image, with the default 2 GiB/dev/gpt/swap
.What more can I add that would be useful?