Improve nitro's performance.
I find that when use backend module to handle system call information,virtual machine performance is degraded,i think it's unreasonable to set vm paused when dealing with system call information,so is there any solution to improve nitro's performance?
Nitro's performance is impacted by mutliple factors
- the interception of the syscalls themselves, which triggers an VM_EXIT everytime the instruction is executed on the CPU
- the VCPU execution being blocked until the userland component listens for the next event and get them
- the context switch to userland
- the processing of the event by the Nitro framework (Python, LibVMI caches being flushed, etc)
There is nothing you can do on 1.
We already improved the performance in kernel by adding the syscall filters, so the VM will continue it's execution immediately if the syscall is not part of the set syscalls that you are looking for.
You can improve how the events are delivered on 2 with an even based mechanism, and not a polling as we do right now. However there is nothing you can do about the fact that the VM is paused while an event is processed. If you change that, the memory will not be consistent.
Hello,i want to improve the performance of vm,so i put syscall event in a queue,then i use a thread to do backend,but it can only get syscall information of swapper and bash,besides it losts many process information,at last it reports a glib error,is my method wrong?If worng,how can i solve it?

Is Nitro running faster with your Thread and Queue ?
Because I don't understand why you made the modifications. You are introducing synchronisation issues, since the main loop just puts the events in the queue and continues the execution, while your thread consumes the events and reads the memory a bit later.
Therefore the memory access is not consistent.
Yes,Nitro running faster with my thread and queue.How can i keep memory access consistent when use one thread get event and one thread backend event?
You can't, or you have to reintroduce synchronisation, which will ruin the threads modification
Hello,i want to know in addition to matching the PGD with the CR3 register, is there any other way to find the process that currently generates the system call?I want to use rsp register to get current process's task_struct,but as syscall and sysret both happen in user mode,so i can only get user stack base address not kernel stack address.