Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Dec 10, 2018, 00:42 UTC
- Message-ID
- <20181210004252.GK890086@genre.crustytoothpaste.net>
- In-Reply-To
- <87r2eqxnru.fsf@evledraar.gmail.com>
On Mon, Dec 10, 2018 at 12:51:01AM +0100, Ævar Arnfjörð Bjarmason wrote:
Show 6 quoted lines
> 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.
Show 5 quoted lines
> 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