RFC: Removing JIT mode from Spicy's Zeek plugin?

Spicy
1

I’ve been pondering making a change to the Spicy plugin for Zeek where I’d be interested in feedback. Right now, there are two ways to have Zeek pull in a Spicy analyzer: (1) pre-compile the analyzer with spicyz into an HLTO file, then give that HLTO file to Zeek to load; and (2) give Spicy source code and EVT files directly to Zeek for compilation just-in-time at startup.

I’m considering removing Option (2).

For operational usage, Option (1) is already the only viable way to go because Option 2 takes too much time: the JIT process is quite slow and leads to Zeek startup times that can reach minutes. For that reason, Option (1) is indeed what all the Zeek packages containing Spicy analyzers are already doing behind the scenes: precompiling into an HLTO. However, Option (2) can still be convinient during analyzer development & testing: as one is iterating on Spicy code, it’s easier to just give it all to Zeek than recompile an HLTO every time.

However, Option (2) has two technical drawbacks. Most importantly, it creates a subtly different setting than a precompiled HLTO file, which prevents us from adding some functionality to the plugin that would otherwise be possible. Specifically, we can’t do anything that requires full knowledge of all Spicy code before loading any Zeek scripts that are depending on any of it (because in JIT mode it’s hard to say when “all Spicy code” has been seen; we might end up encountering further Spicy code after some Zeek scripts have already been loaded). Concretely, this currently puts a blocker on a recent PR to automatically create Zeek record types for Spicy units that are handed over to Zeek script-land (Create Zeek-side record types automatically by rsmmr · Pull Request #149 · zeek/spicy-plugin · GitHub). That PR would allow Spicy programmers to avoid quite a bit of boilerplate code when interfacing analyzers to Zeek. The second (less important) drawback of Option (2) is that it adds complexity to the Spicy plugin at several places that would be nice to avoid.

So, the proposal is to remove the JIT mode from the Zeek plugin: you would now always need to pre-compile analyzers into HLTO files to use them with Zeek. Question is: Would that substantially impact anybody’s workflow?

2

Seems like it would be fine to me. I haven’t ever actually used the JIT workflow. It could be good to explicitly reach out to Keith Jones to try and see what his workflow is.

3

I am in favor of removing the JIT mode from spicy-plugin. That that would allow us to build more powerful features in the plugin is great, but that the removal would enforce best practices would almost be a sufficient reason for removal for me.

Re: potentially harder development work, I would hope that with the existing Spicy zkg templates this should mostly be a non-issue (and again enforce best practices). If there are new gaps in the dev experience due to JIT mode removal, let’s fix them there instead.