[fwsGonzo]

Adds separate SINGLE_PROCESS_MODE and LIBFUZZER_ENABLED. Single-process mode allows you to run varnishd in a single process, which will let you use things like PGO and gprof profiling, but is also required for libfuzzer. Libfuzzer mode makes it so that the varnishd main function returns in a manner which does not call any exit functions. This allows for initializing varnishd once, and then fuzzing against (for example) UNIX sockets shortly after.

[dridi]

We discussed this offline with @fwsGonzo and while in general I like this better than the previous attempt I still have minor nitpicks.

I would like to see 3 patches to make the review easier:

• one that moves some logic to the child_startup() function
• a second one for the single process mode
• and finally one for libfuzzer integration

Regarding single process mode and libfuzzer integration, I notice a distinct lack of autoconf involvement, I can help or deal with that. But first, the nitpicks.

[dridi]

With libfuzzer enabled this early return leaves dead code, there might be a more elegant solution.

[fwsGonzo]

I want to make some changes to panic code when libfuzzer is enabled, but I haven't had time to look at it yet. I don't know what varnish does to handle panics, but I think it might be interfering with the libfuzzer sig handler.

Having said that ... it might be preferrable to not do anything about it as well. Right now we generate coredumps from crashes, which are probably way more useful. Perhaps the solution here is to do nothing.

[dridi]

We either panic explicitly, or have some signal handlers turn signals like SIGSEGV into panics...

[dridi]

Regarding core dumps we have the no_coredump feature flag to disable them.

[dridi]

Bugwash consensus: let's try with a debug flag instead of #ifdef guards.

@fwsGonzo you can add the following to your single process mode patch:

diff --git a/include/tbl/debug_bits.h b/include/tbl/debug_bits.h
index f76eb76ec..915e90505 100644
--- a/include/tbl/debug_bits.h
+++ b/include/tbl/debug_bits.h
@@ -51,6 +51,7 @@ DEBUG_BIT(PROCESSORS,         processors,     "Fetch/Deliver processors")
 DEBUG_BIT(PROTOCOL,            protocol,       "Protocol debugging")
 DEBUG_BIT(VCL_KEEP,            vcl_keep,       "Keep VCL C and so files")
 DEBUG_BIT(LCK,                 lck,            "Additional lock statistics")
+DEBUG_BIT(SINGLE_PROC,         single_proc,    "Run in single process mode")
 #undef DEBUG_BIT
 
 /*lint -restore */

Then it's "only" a matter of doing this:

-#ifndef SINGLE_PROCESS_MODE
+if (!MGT_DO_DEBUG(DBG_SINGLE_PROC)) {
 /* ... */
-#endif
+}

Indent, rinse, repeat... This way as @bsdphk suggested we can have at least some basic coverage in a test case:

varnish v1 -cliok "param.set debug +single_proc"
varnish v1 -vcl+backend {...} -start

And the test case may do a few things like a couple transactions, stopping the child, restarting the child...

[dridi]

One thing we discussed about the single process mode is whether we want it to be "feature-complete".

For example, is it OK that once the child is started as a thread we can't stop and start it again? @fwsGonzo's use case is only libfuzzer support and we don't have such a request from anyone else. This also also breaks process isolation altogether and if we are going for a debug bit we can probably live with the limitation?

On the other hand in order to have some minimal coverage in a VTC to make sure we don't accidentally break single process mode in the future, we also need varnishd to shut down properly.

[dridi]

I did more digging with @fwsGonzo and came to the conclusion that this isn't really single process mode that we need to use libfuzzer. It's rather a sort of "exec" mode where the manager leaves its place to the child and there's no coming back.

One thing I couldn't ensure once we have more than one thread in the manager is that VEV events get delivered to the manager's thread. That would mean having to do ALL the setup BEFORE the child is started in this mode.

[bsdphk]

I'm not keen on this patch for a number of reasons.

Thinking a bit more "high-level" about it, maybe the entire "launch the child excution context" should be a VJ function, so we could have a "single-process" VJ useful for fuzzing, other analysis tools, running debuggers etc.

[bsdphk]

Bugwash: This ticket has served its purpose.

The way forward is something along the lines of VJ_launch_child() and until somebody prototypes that, it is a bit hard to guess precisely what the contour of that should be.