[Webkit-unassigned] [Bug 231674] Support in-process fuzzing of IPC messages

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=231674

--- Comment #6 from Kimmo Kinnunen <kkinnunen at apple.com> ---
It's a great start!

Once this is in, it might be very hard to fix WebKit IPC without breaking the fuzzer. As such it'd be great if:
1) It didn't expect things to be called inside the implementation ad-hoc
2) It used the expected threading model

It's not clear to me whether the "start fuzzing" message is a specific WebKit message you want to override, or do you just want "start fuzzing" message. Below is written from the standpoint that one just wants to start the testing, not override a specific message.

I think more structural approach would be:
1) Define IPC interface IPCTestingAPI.messages.in:
messages -> IPCTester NotRefCounted {
  StartMessageTesting()
}


2) Register this interface in all the project toplevel processes you want to test.

3) When receiving the message, post a task to main runloop to run the externally loaded fuzz driver

4) The fuzz driver should get WebKit function and context in, so that when the fuzz driver calls into webkit with the test case, webkit code can just use the context to setup the call state.

So the pseudocode would be:

extern "C" typedef (*OneInputFunc)(char* data, size_t sz, void* context);

extern "C" void (*messageTestDriver)(OneInputFunc, void* context);

extern "C" void testOneMessage(char* data, size_t sz, void* context)
{
    IPC::Connection* connection = reinterpret_cast<Connection*>(context);
    auto decoder = IPC::Decoder::create(data, sz, nullptr, Vector<IPC::Attachment> { });
    if (!decoder)
        return 0;
    if (!decoder->isValid())
        return 0;
    connection->dispatchIncomingMessageForTesting(WTFMove(decoder));
}

void AuxiliaryProcess::startMessageTesting()
{
    if (!messageTestDriver)
        messageTestDriver = dyldload(..);
    // When receiving the StartMessageTesting, run the tester in next mainloop iteration.
    RunLoop().dispatch([connection = m_connection] {
        m_connection->setIgnoreInvalidMessageForTesting();
        // Ref above keeps the connection alive.
        messageTestDriver(testOneMessage, connection.get());
    }
};

void Connection::dispatchIncomingMessageForTesting(Decoder decoder) {
   m_connectionQueue->dispatch([decoder = WTFMove(decoder)] {
       processIncomingMessage(WTFMove(decoder));
   });
}


--

In your current impl, you'd run your fuzzer driver loop inside one of the Connection private implementation methods for dispatching one message, re-entering the connection message dispatch logic while sending multiple messages. This is not the way it's intended to work.


Note: running the message testing in main loop will have the side-effect that the message processing loop runs concurrently. This means that if other processes send messages to the process you're testing, these messages would be processed in between your test messages. This may or may not interfere with your goal, so care should be taken if this must be further changed. Same with message sends, IIUC correctly, your current never-ending fuzz loop would prevent any messages sent by the tested process to be queued instead of actually sent. When run in main loop, sent messages would be sent business as usual.

also, you could just name the methods, variables and such in "normal webkit way". E.g. ptfFuzzNow, TryLoadPTF all break the logic of the naming. Even if PFT is a project of some kind, it would be less surprising to use just normal, general names to describe the concept.

fuzz == message testing ?
pftFuzzNow == messageTestDriver?

PTFTestOneInputConnection = messageTestOneInput ? testMessage? sendTestMessage ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211015/f664bd05/attachment-0001.htm>