On Mon, Dec 10, 2018 at 12:51:01AM +0100, Ævar Arnfjörð Bjarmason wrote:
> Obviously this & what you have in 2/2 needs to be fixed in some way.
>
> Is the issue on SELinux, OpenBSD, NetBSD etc. *how* PCRE is creating the
> the JIT'd code? I.e. presumably Google Chrome's JIT engine, Java JIT and
> the like work on those setup, or not? I.e. is this something upstream
> can/is likely to fix eventually?
From the cover letter (but without testing), it seems like it would
probably be fine to first map the pages read-write to write the code and
then, once that's done, to map them read-executable. I know JIT
compilation does work on the BSDs, so presumably that's the technique to
make it do so.
Both versions of PCRE map pages both write and executable at the same
time, which is presumably where things go wrong. I assume it can be
fixed, but whether that's easy in the context of PCRE, I wouldn't know.
> Are we mixing a condition where one some OS's or OS versions this just
> won't work at all, and thus maybe should be something turned on in
> config.mak.uname, v.s. e.g. SELinux where presumably it'll dynamically
> change.
Considering that some Linux users use PaX kernels with standard
distributions and that most BSD kernels can be custom-compiled with a
variety of options enabled or disabled, I think this is something we
should detect dynamically.
> I'm inclined to suggest that we should have another ifdef here for "if
> JIT fails I'd like it to die", so that e.g. packages I build (for
> internal use) don't silently slow down in the future, only for me to
> find some months later that someone enabled an overzealous SELinux
> policy and we swept this under the rug.
My view is that JIT is a nice performance optimization, but it's
optional. I honestly don't think it should even be exposed through the
API: if it works, then things are faster, and if it doesn't, then
they're not. I don't see the value in an option for causing things to be
broken if someone improves the security of the system.
--
brian m. carlson: Houston, Texas, US
OpenPGP:
https://keybase.io/bk2204
