News for hackers. Stuff that matters.
Re:Orange_slice: Research Kernel and Hypervisor in Rust by roca on Friday April 12, 2019 @02:05AM (#19642377)
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.
Re:Orange_slice: Research Kernel and Hypervisor in Rust by gamozolabs on Friday April 12, 2019 @03:34AM (#19642804)
My 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!

Re:Orange_slice: Research Kernel and Hypervisor in Rust by nickpsecurity on Friday April 12, 2019 @11:42AM (#19645810)
I 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.cs.umass.edu/~emery/pubs/dthreads-sosp11.pdf

Re:Orange_slice: Research Kernel and Hypervisor in Rust by rambojazz on Friday April 12, 2019 @02:26AM (#19642476)
What is multicore record-and-replay?
Re:Orange_slice: Research Kernel and Hypervisor in Rust by sanxiyn on Friday April 12, 2019 @02:57AM (#19642605)
They say 5x. Is 5x unrealistic?