On Tue, Nov 13, 2018 at 10:17 AM, Kristina Martsenko <kristina.martsenko@xxxxxxx> wrote: > When the PAC authentication fails, it doesn't actually generate an > exception, it just flips a bit in the high-order bits of the pointer, > making the pointer invalid. Then when the pointer is dereferenced (e.g. > as a function return address), it generates the usual type of exception > for an invalid address. Ah! Okay, thanks. I missed that detail. :) What area of memory ends up being addressable with such bit flips? (i.e. is the kernel making sure nothing executable ends up there?) > So when a function return fails in user mode, the exception is handled > in __do_user_fault and a forced SIGSEGV is delivered to the task. When a > function return fails in kernel mode, the exception is handled in > __do_kernel_fault and the task is killed. > > This is different from stack protector as we don't panic the kernel, we > just kill the task. It would be difficult to panic as we don't have a > reliable way of knowing that the exception was caused by a PAC > authentication failure (we just have an invalid pointer with a specific > bit flipped). We also don't print out any PAC-related warning. There are other "guesses" in __do_kernel_fault(), I think? Could a "PAC mismatch?" warning be included in the Oops if execution fails in the address range that PAC failures would resolve into? -Kees -- Kees Cook _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
