linux-kernel - Re: [PATCH v10 1/4] ipc: Allow boot time extension of IPCMNI from 32k to 8M

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:   Tue, 6 Nov 2018 05:20:59 -0800
From:   Matthew Wilcox <willy@...radead.org>
To:     Waiman Long <longman@...hat.com>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org,
        Al Viro <viro@...iv.linux.org.uk>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Takashi Iwai <tiwai@...e.de>, Davidlohr Bueso <dbueso@...e.de>,
        Manfred Spraul <manfred@...orfullife.com>
Subject: Re: [PATCH v10 1/4] ipc: Allow boot time extension of IPCMNI from
 32k to 8M

On Mon, Nov 05, 2018 at 10:43:43AM -0500, Waiman Long wrote:
> The maximum number of unique System V IPC identifiers was limited to
> 32k.  That limit should be big enough for most use cases.
> 
> However, there are some users out there requesting for more, especially
> those that are migrating from Solaris which uses 24 bits for unique
> identifiers. To satisfy the need of those users, a new boot time kernel
> option "ipcmni_extend" is added to extend the IPCMNI value to 8M. This
> is a 256X increase which hopefully is big enough for them.

Why go to 23 bits when people are coming from systems with 24 bits?
Let's just go to 24 bits.  This happens to fit well with the underlying
data structure which uses 6 bits per layer of the tree.

> The use of this new option will change the pattern of the IPC identifiers
> returned by functions like shmget(2). An application that depends on
> such pattern may not work properly.  So it should only be used if the
> users really need more than 32k of unique IPC numbers.

Are there applications out there that rely on the internal structure of
the IPC identifiers?!

How about scrapping all this and just doing the following:

Allocate 24 bits of the ID cyclically.  Increment the top 7 bits of the
ID every time the cursor wraps.  That's not going to give us a perfect
progression from 0-2 billion, because it'll skip the ones in use.
But it'll ensure the ID isn't reused particularly quickly unless the
application is really using millions of IDs.