On Tue, Nov 13, 2018 at 05:09:00PM -0600, Kees Cook wrote: > 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? I'd personally prefer that we didn't try to guess if a fault is due to a failed AUT*, even for logging. Presently, it's not possible to distinguish between a fault resulting from a failed AUT* and a fault which happens to have hte same bits/clear, so there are false positives. The architecture may also change the precise details of the faulting address, and we'd have false negatives in that case. Given that, I think suggesting that a fault is due to a failed AUT* is liable to make things more confusing. Thanks, Mark.
