On Thu, Nov 21, 2024 at 10:18 AM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Mon, Nov 18, 2024 at 10:13:04PM -0800, Andrii Nakryiko wrote: > > On Mon, Nov 18, 2024 at 2:06 AM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > > Yep, on arm64 we definitely can't patch in branches reliably; using BRK > > > (as we do today) is the only reliable option, and it *shouldn't* be > > > slower than a syscall. > > > > > > Looking around, we have a different latent issue with uprobes on arm64 > > > in that only certain instructions can be modified while being > > > concurrently executed (in addition to the atomictiy of updating the > > > > What does this mean for the application in practical terms? Will it > > crash? Or will there be some corruption? Just curious how this can > > manifest. > > It can result in a variety of effects including crashes, corruption of > memory, registers, issuing random syscalls, etc. > > The ARM ARM (ARM DDI 0487K.a [1]) says in section B2.2.5: > > Concurrent modification and execution of instructions can lead to the > resulting instruction performing any behavior that can be achieved by > executing any sequence of instructions that can be executed from the > same Exception level [...] > > Which is to say basically anything might happen, except that this can't > corrupt any state userspace cannot access, and cannot provide a > mechanism to escalate privilege to a higher exception level. > > So that's potentially *very bad*, and we're just getting lucky that most > implementations don't happen to do that for most instructions, though > I'm fairly certain there are implementations out there which do exhibit > this behaviour (and it gets more likely as implementations get more > aggressive). > I see. I wonder if the fact that we do __replace_page() saves us here? Either way, if that's a problem, it would be good for someone familiar with ARM64 to try to address it. Ideally in a way that won't ruin the multi-uprobe attachment speeds (i.e., not doing stop-the-world for each of many uprobe locations to be attached, but rather do that once for all uprobes). > Mark. > > [1] https://developer.arm.com/documentation/ddi0487/ka/?lang=en
