>> Date: Sun, 24 Feb 2019 10:44:25 -0500 >> From: Todd Mortimer <[email protected]> >> >> A few weeks ago I noticed that firefox tabs were getting killed for >> running afoul of pledge(2). It seems that the problem was some calls to >> shmget(2) from the X swrast_dri.so lib that seem to have come from the >> new mesa code that was recently imported. Since the shm syscalls aren't >> covered by any pledge the system was killing the firefox tabs when they >> called into X and X went down this code path. >> >> The shm calls are guarded by a #ifdef, so the patch below just >> modifies the conditions so OpenBSD does not include the shm function and >> falls back to ordinary malloc. With this patch my firefox works again. >> >> The alternative is to add shm to pledge(2) somewhere. I expect that >> adding a syscall to pledge for a single program is unwanted, but in this >> case it would be for any program using X with this DRI module. A quick >> check in xenocara finds a small number of other references to the shm >> functions (lib/libXvMC/src/XvMC.c, lib/xcb-util-image/), but I don't >> know if we use these. >> >> ok? > >Sorry no. I don't think it makes sense to criple an important >optimization. Without shared memory support large bitmaps need to be >transferred across a socket with is a lot slower. > >Maybe we do need a SysV shared memory pledge. But there are >reasonable objections to including pledge support for an archaic >subsystem. > >These days X provides an alternative based on POSIX shared memory and >file descriptor passing. That might be a better match for a pledgable >interface. But the Mesa code doesn't support this yet.
Also, it is always always reasonable disable pledge in a program which cannot fit to the pledge world view. pledge intentionally takes a hard line.
