Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 27 Aug 2018 16:25:43 -0700 | Subject | Re: [PATCH] x86/nmi: Fix some races in NMI uaccess |
| |
On Mon, Aug 27, 2018 at 4:12 PM, Jann Horn <jannh@google.com> wrote: > On Tue, Aug 28, 2018 at 1:04 AM Andy Lutomirski <luto@kernel.org> wrote: >> >> In NMI context, we might be in the middle of context switching or in >> the middle of switch_mm_irqs_off(). In either case, CR3 might not >> match current->mm, which could cause copy_from_user_nmi() and >> friends to read the wrong memory. >> >> Fix it by adding a new nmi_uaccess_okay() helper and checking it in >> copy_from_user_nmi() and in __copy_from_user_nmi()'s callers. > > What about eBPF probes (which I think can be attached to kprobe points > / tracepoints / perf events) that perform userspace reads / userspace > writes / kernel reads? Can those run in NMI context, and if so, do > they also need special handling?
I assume they can run in NMI context, which might be problematic in and of themselves. For example, does BPF adequately protect against a BPF program accessing a map while bpf(2) is modifying it? It seems like bpf_prog_active is intended to serve this purpose.
But I don't see any obvious mechanism for eBPF programs to read user memory.
| |