[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2cfb3835-0c18-b3fb-1722-5d693ae0ecd2@gmail.com>
Date: Wed, 31 Oct 2018 00:15:46 +0200
From: Igor Stoppa <igor.stoppa@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Matthew Wilcox <willy@...radead.org>, Tycho Andersen <tycho@...ho.ws>,
Kees Cook <keescook@...omium.org>, Peter Zijlstra <peterz@...radead.org>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>, Dave Chinner <david@...morbit.com>,
James Morris <jmorris@...ei.org>, Michal Hocko <mhocko@...nel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
linux-integrity <linux-integrity@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
Igor Stoppa <igor.stoppa@...wei.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, Jonathan Corbet <corbet@....net>,
Laura Abbott <labbott@...hat.com>, Randy Dunlap <rdunlap@...radead.org>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 10/17] prmem: documentation
On 30/10/2018 23:02, Andy Lutomirski wrote:
>
>
>> On Oct 30, 2018, at 1:43 PM, Igor Stoppa <igor.stoppa@...il.com> wrote:
>> There is no need to process each of these tens of thousands allocations and initialization as write-rare.
>>
>> Would it be possible to do the same here?
>
> I don’t see why not, although getting the API right will be a tad complicated.
yes, I have some first-hand experience with this :-/
>>
>>>>>
>>>>> To subsequently modify q,
>>>>>
>>>>> p = rare_modify(q);
>>>>> q->a = y;
>>>>
>>>> Do you mean
>>>>
>>>> p->a = y;
>>>>
>>>> here? I assume the intent is that q isn't writable ever, but that's
>>>> the one we have in the structure at rest.
>>> Yes, that was my intent, thanks.
>>> To handle the list case that Igor has pointed out, you might want to
>>> do something like this:
>>> list_for_each_entry(x, &xs, entry) {
>>> struct foo *writable = rare_modify(entry);
>>
>> Would this mapping be impossible to spoof by other cores?
>>
>
> Indeed. Only the core with the special mm loaded could see it.
>
> But I dislike allowing regular writes in the protected region. We really only need four write primitives:
>
> 1. Just write one value. Call at any time (except NMI).
>
> 2. Just copy some bytes. Same as (1) but any number of bytes.
>
> 3,4: Same as 1 and 2 but must be called inside a special rare write region. This is purely an optimization.
Atomic? RCU?
Yes, they are technically just memory writes, but shouldn't the "normal"
operation be executed on the writable mapping?
It is possible to sandwich any call between a rare_modify/rare_protect,
however isn't that pretty close to having a write-rare version of these
plain function.
--
igor
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
