linux-kernel - Re: Robust shared memory for unrelated processes

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] [day] [month] [year] [list]

Date:	Sun, 23 Nov 2008 17:43:24 -0600
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Chris Smowton <chris.smowton@...cam.ac.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Robust shared memory for unrelated processes

Quoting Chris Smowton (chris.smowton@...cam.ac.uk):
> Hello all,
>
> First of all, my apologies if this is the wrong list for this suggestion; I 
> haven't posted here before so I might accidentally break some local 
> conventions :)
>
> With that said, my question/suggestion relates to sharing memory between 
> processes which are *not* in a parent-child relationship.
>
> Suppose for simplicity's sake that one wishes to share a sizable piece of 
> memory with a single other process with which one is already in contact 
> (say, by a Unix domain socket).
>
> It seems to me that one cannot do this without introducing the risk of the 
> shared section not being deallocated until the system next boots, for the 
> following reasons:
>
> 1. Suppose I use SysV style SHM. Then I must find a free key, create a 
> section with that key, and communicate that key to my partner process so 
> that he can also open the section. I cannot issue an IPC_RMID during this 
> time, as that will render the key immediately unavailable. If I am 
> SIGKILL'd at any time between creating the section and receiving 
> confirmation that my partner has opened it, the section will persist until 
> reboot. This is a large window of opportunity and a very bad thing.

Ah, but if your app is started in a new IPC namespace, then when the
app dies, the namespace will be released and the section will be freed.

Now both of the processes will need to be started in the same child
ipc namespace, as you currently can't enter an existing ipcns.  If
that is a problem, I'm sure it can be addressed somehow.

-serge
--
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/