arm64: initialize pcb in the TBI/PAC/etc. fault case

[kevans]

Summary

After 2c10be9e06d, we may jump to the bad_far label without pcb being
set, resulting in a follow-up fault as we may dereference it immediately
after the jump if td_intr_nesting_level == 0. In this branch, it should
be safe to dereference td as we're not handling the special case
mentioned below of accessing it during promotion/demotion.

This seems to fix a null ptr deref I hit during my most recent pkgbase
build attempt on the Windows DevKit.

Fixes: 2c10be9e06d ("arm64: Handle translation faults for thread [..]")

[markj]

Seems ok to me, but:

This seems to fix a null ptr deref I hit

Could you please elaborate a bit further? Upon a NULL pointer deref I'd expect FAR to contain 0, in which case we shouldn't take the !ADDR_IS_CANONICAL path.

[andrew]

sys/arm64/arm64/trap.c

371

This is the NULL pointer dereference

[markj]

sys/arm64/arm64/trap.c

371

How did the original fault arise? PAC is disabled on devkits.

[andrew]

sys/arm64/arm64/trap.c

371

It doesn't have to be PAC, just any invalid address that's not in the kernel or user address spaces.

[kevans]

sys/arm64/arm64/trap.c

371

Yeah, I suspect I was on the way to a panic anyways based on where the first fault was... currently working on building a functional version of kgdb so that I can confirm the details

[kevans]

sys/arm64/arm64/trap.c

371

Ok, I fixed kgdb enough to confirm that I was on the way to a panic, some use-after-free in ZFS so it was trying to deref some offset from 0xdeadc0dedeadc0de, which would fit the bill for non-canonical address. So this wouldn't have actually fixed the panic, but it at least would have revealed the real reason for panicking.