On Mon, Aug 21, 2017 at 08:23:10AM -0700, Andy Lutomirski wrote: > > Ah, but only root can create per-cpu events or attach events to kernel > > threads (with sensible paranoia levels). > > But this may not need to be percpu. If a non root user can trigger, say, an > EFI variable read in their own thread context, boom.
I was going by the proposed: "everything EFI in a kthread" model. But yes, if that's not done, then you're quite right. > > > >> The other is that, if EFI were to have IO memory mapped at a "user" > >> address, perf could end up reading it. > > > > Ah, but in neither mode does perf assume much, the LBR follows branches > > the CPU took and thus we _know_ there was code there, not MMIO. And the > > stack unwind simply follows the stack up, although I suppose it could be > > 'tricked' into probing MMIO. We can certainly add an "->mm != > > ->active_mm" escape clause to the unwind code. > > > > Although I don't see how we're currently avoiding the same problem with > > existing userspace unwinds, userspace can equally have MMIO mapped. > > But user space at least only has IO mapped to which the user program in > question has rights. Still, we should not mess it up just because we're trying to unwind stacks.
