On Wed, Nov 14, 2018 at 3:47 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > 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. Okay, no worries. It should be pretty clear from the back trace anyway. :) As long as there isn't any way for the pointer bit flips to result in an addressable range, I'm happy. :) -Kees -- Kees Cook _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
