linux-kernel - Re: [PATCH v6 02/10] x86, mpx: add MPX specific mmap interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Jun 2014 10:34:49 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	"Ren, Qiaowei" <qiaowei.ren@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux MM <linux-mm@...ck.org>
Subject: Re: [PATCH v6 02/10] x86, mpx: add MPX specific mmap interface

On 06/26/2014 05:26 PM, Andy Lutomirski wrote:
> On Thu, Jun 26, 2014 at 5:19 PM, Dave Hansen <dave.hansen@...el.com> wrote:
>> On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
>>> Also, egads: what happens when a bound table entry is associated with
>>> a MAP_SHARED page?
>>
>> Bounds table entries are for pointers.  Do we keep pointers inside of
>> MAP_SHARED-mapped things? :)
> 
> Sure, if it's MAP_SHARED | MAP_ANONYMOUS.  For example:
> 
> struct thing {
>   struct thing *next;
> };
> 
> struct thing *storage = mmap(..., MAP_SHARED | MAP_ANONYMOUS, ...);
> storage[0].next = &storage[1];
> fork();
> 
> I'm not suggesting that this needs to *work* in the first incarnation of this :)

I'm not sure I'm seeing the issue.

I'm claiming that we need COW behavior for the bounds tables, at least
by default.  If userspace knows enough about the ways that it is using
the tables and knows how to share them, let it go to town.  The kernel
will permit this kind of usage model, but we simply won't be helping
with the management of the tables when userspace creates them.

You've demonstrated a case where userspace might theoretically might
want to share bounds tables (although I think it's pretty dangerous).
It's equally theoretically possible that userspace might *not* want to
share the tables for instance if one process narrowed the bounds and the
other did not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/