Messages in this thread | | | From | Kees Cook <> | Date | Tue, 13 Nov 2018 17:09:00 -0600 | Subject | Re: [PATCH 00/17] ARMv8.3 pointer authentication support |
| |
On Tue, Nov 13, 2018 at 10:17 AM, Kristina Martsenko <kristina.martsenko@arm.com> 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
| |