Simulating data races/concurrent modification in fuzzing

I'm trying to fuzz postcard and by extension serde. I'd like to -- in future -- use it for a message format in my kernel. However, to do that I need to be able to determine how these libraries will react when a data race occurs, as two processors may write to the same page simultaneously, or two programs may concurrently modify the message, one correctly doing the write and another tampering with the message. Currently my fuzzing looks like this:

#![no_main]
use libfuzzer_sys::fuzz_target;
use postcard::from_bytes;
use serde::{Deserialize, Serialize};

#[repr(C)]
#[derive(
    Clone, Copy, Debug, Default, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize,
)]
struct ReadRequest {
    pub fd: u64,
    pub buf_addr: u64,
    pub size: usize,
}

fuzz_target!(|data: &[u8]| {
    match from_bytes::<ReadRequest>(data) {
        Ok(mut req) => {
            req.fd = 0;
            req.buf_addr = 0;
            req.size = 0;
        }
        Err(_) => {}
    }
});

This attempts to simulate an equivalent to the read system call:

#include <unistd.h>

ssize_t read(int fd, void *buf, size_t count);

Or, in rust:

use syscall::{platform::*, nr::*};

unsafe {
syscall3(READ, fd, buf, count);
}

What is the proper way to simulate this?

I have never tried this but I have heard say that loom is a good way to test parallel codes:
https://github.com/tokio-rs/loom

Regular fuzzing cannot exercise all the different timing/ordering of execution of threads that might trigger some failure.

But I presume postcard/serde do not support working across threads. So if you have set them up to work in and out of memory shared across threads somehow you need to be testing your code that synchronises access to that memory, not postcard/serde themselves.

I don't think this'll work. This is the first time I've ever fuzzed a program like this and with these particular parameters so there just might not be a way to do it without letting entropy do it for me.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.