Re: Neuter shm calls from X swrast_dri.so
>> Date: Sun, 24 Feb 2019 10:44:25 -0500 >> From: Todd Mortimer >> >> 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.
Re: Neuter shm calls from X swrast_dri.so
> Date: Sun, 24 Feb 2019 10:44:25 -0500 > From: Todd Mortimer > > 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. > Index: lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c > === > RCS file: /cvs/xenocara/lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c,v > retrieving revision 1.7 > diff -u -p -u -r1.7 dri_sw_winsys.c > --- lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c19 Feb 2019 > 04:24:01 - 1.7 > +++ lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c24 Feb 2019 > 15:16:35 - > @@ -26,8 +26,9 @@ > * > **/ > > -#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26 > +#if (!defined(ANDROID) || ANDROID_API_LEVEL >= 26) && !defined(__OpenBSD__) > /* Android's libc began supporting shm in Oreo */ > +/* OpenBSD does not allow shm in programs using pledge(2) */ > #define HAVE_SHM > #include > #include > > >
Re: Neuter shm calls from X swrast_dri.so
On Sun, Feb 24, 2019 at 10:44:25AM -0500, Todd Mortimer wrote: > 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. Thanks for looking into this, and nice findings ! There has been some discussion to add an 'shm' pledge class, but no real usage surfaced so far, and the usual stance was to neuter the shmget calls so that fallback codepaths were used like in https://bugzilla.mozilla.org/show_bug.cgi?id=1457092. - maybe there are more in other programs.. but there would have been a lot of pledge reports if so.
Neuter shm calls from X swrast_dri.so
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? Index: lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c === RCS file: /cvs/xenocara/lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c,v retrieving revision 1.7 diff -u -p -u -r1.7 dri_sw_winsys.c --- lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c 19 Feb 2019 04:24:01 - 1.7 +++ lib/mesa/src/gallium/winsys/sw/dri/dri_sw_winsys.c 24 Feb 2019 15:16:35 - @@ -26,8 +26,9 @@ * **/ -#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26 +#if (!defined(ANDROID) || ANDROID_API_LEVEL >= 26) && !defined(__OpenBSD__) /* Android's libc began supporting shm in Oreo */ +/* OpenBSD does not allow shm in programs using pledge(2) */ #define HAVE_SHM #include #include
