# PaX MPROTECT / W^X protection - Thread: https://externals.io/message/96837 - Original archive: https://news-web.php.net/php.internals/96837 - Started by Christoph M. Becker on 2016-11-11T18:40:12+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #96837 — Christoph M. Becker — 2016-11-11T18:40:12+00:00 URL: https://externals.io/message/96837#96837 Hi! There are currently at least two unresolved tickets[1][2] in our bug tracker regarding PaX MPROTECT / W^X protection issues with regard to PCRE JIT. The problem is that PCRE JIT mmaps W|X pages[3], what is no longer allowed on several platforms, such as OpenBSD, FreeBSD and SELinux. It seems that there are workarounds (e.g. using paxctl to allow W|X mapping[1], or mounting with wxallowed[4]), but these appear to be very system specific. My best idea to resolve the reports is to document this issue. Maybe somebody has a better idea? [1] [2] [3] [4] -- Christoph M. Becker --- ## #96866 — Anatol Belski — 2016-11-12T20:25:17+00:00 URL: https://externals.io/message/96837#96866 · In reply to: #96837 Hi Christoph, > -----Original Message----- > From: Christoph M. Becker [mailto:cmbecker69@gmx.de] > Sent: Friday, November 11, 2016 7:40 PM > To: internals@lists.php.net > Subject: [PHP-DEV] PaX MPROTECT / W^X protection > > Hi! > > There are currently at least two unresolved tickets[1][2] in our bug tracker > regarding PaX MPROTECT / W^X protection issues with regard to PCRE JIT. The > problem is that PCRE JIT mmaps W|X pages[3], what is no longer allowed on > several platforms, such as OpenBSD, FreeBSD and SELinux. It seems that there > are workarounds (e.g. using paxctl to allow W|X mapping[1], or mounting with > wxallowed[4]), but these appear to be very system specific. > > My best idea to resolve the reports is to document this issue. Maybe somebody > has a better idea? > AFM, the linked tickets are not about an issue in PHP. There are just systems, or system configurations, that are very security oriented. If some feature is disabled on the system level, there's not much PHP can do. To compare - it were wrong same way to say atime doesn't work in PHP, if indeed a volume is mounted with atime disabled. Any issue, that is only to be solved by the system configuration, is a configuration issue in the most case. So the documentation is probably the only what we can do in the case. Regrads Anatol --- ## #96872 — Joe Watkins — 2016-11-13T06:36:51+00:00 URL: https://externals.io/message/96837#96872 · In reply to: #96866 Morning, Just wanted to give a thumbs up to documenting the issue ... Trying to work around it with platform/distro/kernel specific solutions, sounds quite horrible, and is bound to be fragile. Cheers Joe On Sat, Nov 12, 2016 at 8:25 PM, Anatol Belski wrote: > Hi Christoph, > > > […] > tracker > > […] > The > > […] > there > > […] > with > > […] > somebody > > […] > AFM, the linked tickets are not about an issue in PHP. There are just > systems, or system configurations, that are very security oriented. If some > feature is disabled on the system level, there's not much PHP can do. To > compare - it were wrong same way to say atime doesn't work in PHP, if > indeed a volume is mounted with atime disabled. Any issue, that is only to > be solved by the system configuration, is a configuration issue in the most > case. So the documentation is probably the only what we can do in the case. > > Regrads > > Anatol --- ## #96874 — Christoph M. Becker — 2016-11-13T14:00:06+00:00 URL: https://externals.io/message/96837#96874 · In reply to: #96872 Thanks, Anatol and Joe! So I'm going to document these issues, and close the respective reports. Cheers, Christoph > Morning, > > Just wanted to give a thumbs up to documenting the issue ... > > Trying to work around it with platform/distro/kernel specific solutions, > sounds quite horrible, and is bound to be fragile. > > Cheers > Joe > > On Sat, Nov 12, 2016 at 8:25 PM, Anatol Belski > wrote: > > > […] --- ## #97348 — Christoph M. Becker — 2016-12-09T15:01:15+00:00 URL: https://externals.io/message/96837#97348 · In reply to: #96874 An update regarding the PaX MPROTEXT / W^X protection issue: Zoltan Herczeg added a new compile flag which is supposed to avoid this issue, see for details. Perhaps something to consider for our builds? Cheers, Christoph > Thanks, Anatol and Joe! So I'm going to document these issues, and > close the respective reports. > > Cheers, > Christoph > > > > > […] --- ## #97408 — Anatol Belski — 2016-12-14T18:48:01+00:00 URL: https://externals.io/message/96837#97408 · In reply to: #97348 Hi Christoph, > -----Original Message----- > From: Christoph M. Becker [mailto:cmbecker69@gmx.de] > Sent: Friday, December 9, 2016 4:01 PM > To: Joe Watkins ; Anatol Belski > > Cc: PHP internals > Subject: Re: [PHP-DEV] PaX MPROTECT / W^X protection > > An update regarding the PaX MPROTEXT / W^X protection issue: Zoltan Herczeg > added a new compile flag which is supposed to avoid this issue, see > for details. > > Perhaps something to consider for our builds? > Thanks for keeping an eye on it. One could care about it, as an optional feature, yep. How it sounds, it could still improve performance on systems with strict configuration, while increasing memory usage. I'd see the urgency as low, as the functional part is now ensured by --with-pcre-jit=no. Thanks Anatol > Cheers, > Christoph > > > > > […] > documentation is probably the only what we can do in the case. > > […] > > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php