Re: [PATCH 10/17] prmem: documentation
From: Kees Cook
Date: Tue Oct 30 2018 - 15:14:59 EST
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;
> 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:
It just needs the switch_mm() backend.