Closed Bug 516716 (Fuzz-IPDL) Opened 12 years ago Closed 4 years ago
Dynamic fuzzing of IPDL (generically)
We'd like to dynamically fuzz IPDL to verify that any sequence of messages allowed by the IPDL protocol cannot generate protocol errors (and therefore kill the child process). It should be possible to generate the fuzzer directly from the IPDL protocol declarations.
Hrm, this might be a dup of bug 506303. cjones, are they equivalent?
Comment 0 describes a dup of bug 506303, yeah. But if this task is what I remember, it's to fuzz the *IPDL* infrastructure. That is, take any random protocol and inject as many system-level errors as possible, and make sure the IPDL code can tolerate the error and clean up properly. Some examples of system-level errors are the IPC pipe closing at arbitrary times, child process crashing (maybe the same), failed write to the pipe, failed read, failure to serialize/deserialize data, and so forth.
Duplicate of this bug: fuzzing-ipc-ipdl
Summary: Dynamic fuzzing of IPDL → Dynamic fuzzing of IPDL (generically)
There are three levels at which it's most useful to "fuzz" the IPC system - first is OS level fault injection. Adding code to content processes to randomly crash, close IPC sockets, and send-known bad data like fds. This is relatively straightforward and we may be able to use existing tools. It would be most useful to run these during test suites. - second is socket-level "dumb" fuzzing of protocols. After some random amount of time, start writing random garbage to the IPC sockets from content processes. Again, this would be useful to run during test suites. This is quite straightforward. - third is protocol-level "smart" fuzzing of protocols. Use the .ipdl files themselves to generate code to write malicious IPC messages, randomly. More specifically, randomly replace a requested message to be sent with a maliciously-constructed one. The idea here is, when you see int32_t in messages, send extreme values like INT32_MAX, INT32_MIN. Send "", "\0f", really long strings for string parameters. Send random IDs in slots where valid actor IDs are supposed to go. Etc. This is pretty difficult. I would recommend going from first level to third. I provide more specifics about where to hook in fuzzing code for each.
Really want this, can ship with out it.
blocking-basecamp: + → ---
Per IRC conversations with a few other folks, I think the best course of action if there is disagreement on whether this blocks or not is to do the following: - Move the blocking-basecamp flag to ? for re-evaluation - Indicate a rationale for why you disagree
blocking-basecamp: --- → ?
4 years ago
cdiehl, can we open this up? I dont think it needs to be hidden? Also note that bug 1359755 is to implement the protocol level fuzzer (part 3) as referenced in comment 4.
See Also: → 1359755
Closing this as the dup contains the actual work here.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: fuzzing-ipc-ipdl
You need to log in before you can comment on or make changes to this bug.