On 6/9/20 1:50 AM, Tamas K Lengyel wrote: > On Mon, Jun 8, 2020 at 3:16 PM Razvan Cojocaru > <[email protected]> wrote: >> 1. A security application that is unable to _prevent_ things being done >> to a system is not doing a very good job, since in that case you can >> only collect stats and not veto anything. I would argue that the default >> for such a monitoring application should be the current one (all events >> should be pre-action). > > Not all security applications require this though. Malware analysis > where stealth is required would absolutely not want this side-effect > to be visible to the guest where malware could use it to determine > that it's being monitored. So I don't buy into this argument.
Fair enough, in that case having both models supported should be fine. I'll leave the rest of that conversation to my colleagues. >> 2. This is further supported by the fact that that's exactly how the EPT >> vm_events work: you get a "I want to write to this page" event _before_ >> the write occurs. If register writes behave differently, you have _two_ >> different models: one where you get an event post-action, and one where >> you get one pre-action. > > Whether you get an event before or after the effects of the event have > been applied to the system state shouldn't matter as long as you can > revert that action. I wouldn't care either way to be the default. But > having a default that breaks other use-cases is unacceptable. You keep saying that as if I disagree. :) But we've already established that the potential for a race condition has been found and needs to be fixed. My only (minor) objection has been that a patch fixing the current model would have been preferable to one that switches the default as a workaround. Still, it's understandable that perhaps there's no time or motivation for that. Thanks for the work, Razvan
