On Thu, Mar 12, 2020 at 06:42:11PM +0000, Catalin Marinas wrote:

On Wed, Mar 11, 2020 at 05:25:56PM +0000, Mark Brown wrote:

quoted

On Wed, Mar 11, 2020 at 04:28:58PM +0000, Catalin Marinas wrote:

quoted

quoted

Can we not change aarch64_insn_is_nop() to actually return true only for
NOP and ignore everything else in the hint space? We tend to re-use the

quoted

ignored. This isn't extensive userspace testing though.  Adding
whitelisting of the BTI and PAC hints would definitely be a safer as a
first step though.  I can post either version?

I thought BTI and PAC are already whitelisted in mainline as they fall
into the hint space (by whitelisting I mean you can probe them).

This was in the context of your comment above about modifying
aarch64_insn_is_nop() - if we do that and nothing else then we'd remove
the current whitelisting.

I'm trying to understand how the BTI patches affect the current uprobes
support and what is needed. Executing BTI or PCI?SP out of line should
be fine as they don't generate a BTI exception (the BRK doesn't either,
just the normal debug exception).

Right.

I think (it needs checking) that BRK preserves the PSTATE.BTYPE in SPSR.

Yes, Exception_SoftwareBreakpoint preserves PSTATE.BTYPE.

If we probe an instruction in a guarded page and then we single-step it
in a non-guarded page, we'll miss a potential BTI fault. Is this an
issue?

Obviously the main thing here is that if we miss faults then that's
potentially opening something that could be used as part of an exploit
chain.  I'm not aware of any sensible applications that would generate
the exceptions in normal operation.

If we are to keep the BTI faulting behaviour, we'd need an additional
xol page, guarded, and to find a way to report the original probed
address of the fault rather than the xol page.

Yes, or just accept the inaccurate fault address which isn't good but
might be the least worst thing if there's issues with reporting the
original address.

So, IIUC, we don't have an issue with the actual BTI or PACI?SP
instructions but rather the other instructions that would not fault with
the BTI support. While we should try to address this, I think the
important bit now is not to break the existing uprobes support when
running a binary with BTI enabled.

I think so, and as far as my ability to tell goes the worst consequence
would be missing exceptions like you say.  That's not great but it's at
least an extra hoop people have to jump through.