3 ms·
There is one really big technical issue here which I don't see answered on the site: given "it will be multiprocessing from day one", how are they going to hand
by roca 8y ago
There is one really big technical issue here which I don't see answered on the site: given "it will be multiprocessing from day one", how are they going to handle data races deterministically and efficiently? This is the issue that has made all previous attempts to implement multicore record-and-replay quite inefficient.
- rambojazz 8y agoWhat is multicore record-and-replay?
- sanxiyn 8y agoThey say 5x. Is 5x unrealistic?
- gamozolabs 8y agoMy apologies, I wasn't very clear in my readme. It's intended the kernel itself is multiprocessing (support for multiple cores, and multiple VMs). But currently the intent is only to run a single core per VM for now, as getting VT-x or SVM to be deterministic on a single core itself will be hard enough. If we accomplish this, then the next goal would be to maybe look at multiple cores. It is important that I can run multiple single core VMs on a single machine as I plan to use this framework for fuzzing, and retrofitting multiprocessing to a kernel is always a source of many, many bugs. Hope that clears it up a bit!
- nickpsecurity 8y agoI saved a few papers on deterministic multithreading both to knock out concurrency errors and support formal verification. I'm not sure how helpful they are in your use case. I'm just dropping them in case they give you ideas: https://people.csail.mit.edu/mareko/asplos073-olszewski.pdf https://people.csail.mit.edu/mareko/asplos073-olszewski.pdf https://people.cs.umass.edu/~emery/pubs/dthreads-sosp11.pdf https://people.cs.umass.edu/~emery/pubs/dthreads-sosp11.pdf