Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97408
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Christoph M. Becker'" <cmbecker69@gmx.de>,
	"'Joe Watkins'" <pthreads@pthreads.org>
Cc: "'PHP internals'" <internals@lists.php.net>
References: <5eea66e9-0e47-852a-8720-7c7a6a0d2224@gmx.de> <0ca201d23d22$e3d623d0$ab826b70$@belski.net> <CAL=_i_=VpCtNWzF5re7h7puvRNpFED=g+E+g3hyko_z64d9xXg@mail.gmail.com> <05b7feed-3a0a-efd4-7923-a363d3d3c12c@gmx.de> <b102c4c8-17ad-a46d-5bf9-cd5269f8b32d@gmx.de>
In-Reply-To: <b102c4c8-17ad-a46d-5bf9-cd5269f8b32d@gmx.de>
Date: Wed, 14 Dec 2016 19:48:01 +0100
Message-ID: <003301d2563a$9dc597f0$d950c7d0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGhhl8nlm7vhO4uD7RW7udIH5N6sgGACrt9AhTra1YCnOFGYQC2qjCEoTIhq4A=
Content-Language: en-us
Subject: RE: [PHP-DEV] PaX MPROTECT / W^X protection
From: anatol.php@belski.net ("Anatol Belski")

Hi Christoph,

> -----Original Message-----
> From: Christoph M. Becker [mailto:cmbecker69@gmx.de]
> Sent: Friday, December 9, 2016 4:01 PM
> To: Joe Watkins <pthreads@pthreads.org>; Anatol Belski
> <anatol.php@belski.net>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] PaX MPROTECT / W^X protection
>=20
> 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=3D1749#c15> for details.
>=20
> Perhaps something to consider for our builds?
>=20
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=3Dno.

Thanks

Anatol

> Cheers,
> Christoph
>=20
> On 13.11.2016 at 15:00, Christoph M. Becker wrote:
>=20
> > 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.php@belski.net>
> >> wrote:
> >>
> >>> 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
> >>>
> >>>
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List To =
unsubscribe,
> >>> visit: http://www.php.net/unsub.php
> >>>
> >>>
> >>
> >
>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, =
visit:
> http://www.php.net/unsub.php