Hi Christoph, > -----Original Message----- > From: Christoph M. Becker [mailto:cmbecke...@gmx.de] > Sent: Friday, December 9, 2016 4:01 PM > To: Joe Watkins <pthre...@pthreads.org>; Anatol Belski > <anatol....@belski.net> > Cc: PHP internals <internals@lists.php.net> > 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 > <https://bugs.exim.org/show_bug.cgi?id=1749#c15> 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 > > On 13.11.2016 at 15:00, Christoph M. Becker wrote: > > > Thanks, Anatol and Joe! So I'm going to document these issues, and > > close the respective reports. > > > > Cheers, > > Christoph > > > > On 13.11.2016 at 07:36, Joe Watkins wrote: > > > >> 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 > >> <anatol....@belski.net> > >> wrote: > >> > >>> Hi Christoph, > >>> > >>>> -----Original Message----- > >>>> From: Christoph M. Becker [mailto:cmbecke...@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 > >>> > >>> > >>> > >>> -- > >>> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > >>> visit: http://www.php.net/unsub.php > >>> > >>> > >> > > > > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
