In bug 1479960, adding shared memory freezing, to simplify the changes I'm removing the support for SHM_ANON (a FreeBSD extension to shm_open similar to Linux's memfd_create) that I previously added. It could be readded for the non-freezeable case, but it's not essential and I'm breaking it out into a separate bug.

Specifically, it means we can make one system call instead of two (shm_open + shm_unlink), and there's no chance of leaking a shared memory object in the unlikely case of a crash between those operations.

FreeBSD 13.0 can use bug 1440203 for freezeable case, see https://reviews.freebsd.org/D21393.

We can use cap_rights_limit for freezing and that's backwards compatible all the way to 10.x if not even 9.x, if I understand freezing correctly.

(and yes, this is not undoable even outside of the capability mode sandbox, I just tried to set CAP_READ first and then set CAP_MMAP_R — "Capabilities insufficient")

it means we can make one system call instead of two (shm_open + shm_unlink), and there's no chance of leaking a shared memory object in the unlikely case of a crash between those operations

Also, avoids any possible filesystem problems (e.g. posix_fallocate not being supported by ZFS… well, not supported by shm either, but with shm the behavior is consistent on all machines)

and is absolutely necessary for Capsicum sandboxing which I'm working on :)

Comment on attachment 9119576 [details]
Bug 1550891 - re-add SHM_ANON support in IPC shared memory, freezing via capabilities

Applied downstream after fixing style issues:

#ifdef XP_FREEBSD

XP_* is cruft from Netscape days. If required for cross-compilation the whole tree needs to be converted.

#pragma GCC visibility push(default)
#  include <sys/capsicum.h>
#pragma GCC visibility pop

Add sys/capsicum.h to config/system-headers.mozbuild in order to avoid pragmas every time the file is used.

(In reply to greg v [:myfreeweb] from comment #3)

not undoable even outside of the capability mode sandbox

Calling dup before cap_rights_limit would retain write permissions e.g., for use by main process.

(In reply to Jan Beich from comment #4)

XP_* is cruft from Netscape days. If required for cross-compilation the whole tree needs to be converted.

Huh, I saw XP_*BSD was added recently (for OpenBSD's pledge or something like that), I thought it's sort of more "proper". It's used in the fairly recent sandboxing code (grep for defined(XP_LINUX) && defined(MOZ_SANDBOX))…

Add sys/capsicum.h to config/system-headers.mozbuild in order to avoid pragmas every time the file is used.

Wow, thanks for the tip! :)

(In reply to greg v [:myfreeweb] from comment #5)

saw XP_*BSD was added recently

In bug 1457092, because Mozilla preprocessor doesn't have __OpenBSD__ (or similar) predefined macros. XP_* makes it PITA to reuse code elsewhere or reason about outside of Gecko. XP_LINUX in particular is notorious for confusing desktop Linux and Android, leading to https://wiki.mozilla.org/Platform/Platform-specific_build_defines

# How useful XP_LINUX usage actually is?
$ rg --sort-files -l -T rust -T cpp -T c XP_LINUX
browser/app/profile/firefox.js
browser/installer/package-manifest.in
browser/themes/shared/jar.inc.mn
build/moz.configure/init.configure
modules/libpref/init/StaticPrefList.yaml
modules/libpref/init/all.js
python/mozbuild/mozbuild/artifacts.py
toolkit/content/aboutSupport.xhtml
toolkit/content/license.html
toolkit/modules/AppConstants.jsm

It's used in the fairly recent sandboxing code

See OpenBSD example. Using XP_FREEBSD for setting default prefs should be fine.

Sorry for losing track of this. It was going to (and will) conflict with bug 1440203 (and semi-related cleanup extracted into bug 1662564), so I was going to deal with both of them at the same time, but 1440203 has spent a lot of time waiting to not be interrupted by something else.

The other thing about bug 1440203 is that, inspired by comment #1 here, I added a case for FreeBSD 13's memfd_create, also using Capsicum for freezing / read-only copy (same idea as this patch but I think I wrote it before that); it's basically the same structure as the Linux case, which also has to do OS-specific things to get a “dup but read-only” operation. (File seals aren't quite enough; see bug 1550900 and bug 1440203 comment #10.)

But what I haven't done is support SHM_ANON for older OS versions, so that still leaves something for this bug to do. It should be relatively simple once the dust settles.