On Tue, Oct 30, 2018 at 11:51 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > >> On Oct 30, 2018, at 10:58 AM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: >> >> On Tue, Oct 30, 2018 at 10:06:51AM -0700, Andy Lutomirski wrote: >>>> On Oct 30, 2018, at 9:37 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>> I support the addition of a rare-write mechanism to the upstream kernel. >>> And I think that there is only one sane way to implement it: using an >>> mm_struct. That mm_struct, just like any sane mm_struct, should only >>> differ from init_mm in that it has extra mappings in the *user* region. >> >> I'd like to understand this approach a little better. In a syscall path, >> we run with the user task's mm. What you're proposing is that when we >> want to modify rare data, we switch to rare_mm which contains a >> writable mapping to all the kernel data which is rare-write. >> >> So the API might look something like this: >> >> void *p = rare_alloc(...); /* writable pointer */ >> p->a = x; >> q = rare_protect(p); /* read-only pointer */ >> >> To subsequently modify q, >> >> p = rare_modify(q); >> q->a = y; >> rare_protect(p); > > How about: > > rare_write(&q->a, y); > > Or, for big writes: > > rare_write_copy(&q, local_q); > > This avoids a whole ton of issues. In practice, actually running with a special mm requires preemption disabled as well as some other stuff, which Nadav carefully dealt with. This is what I had before, yes: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/write-rarely&id=9ab0cb2618ebbc51f830ceaa06b7d2182fe1a52d It just needs the switch_mm() backend. -- Kees Cook
