3 ms·
Everything you described is already available on Windows in userland via filters (FileSystemWatcher/ReadDirectoryChangesW, RegNotifyChangeKeyValue, et al). Obvi
by Someone1234 5y ago
Everything you described is already available on Windows in userland via filters (FileSystemWatcher/ReadDirectoryChangesW, RegNotifyChangeKeyValue, et al). Obviously you can only monitor whatever lives in your security context.
eBPF looks cool since it is a VM, that could have access to more kernel structures (network?), but solving the issues you described is largely a solved problem on the platform.
- GordonS 5y agoNope, with FileSystemWatcher (and the Windows APIs it uses under the hood) you get minimal information - only using a driver can you get contextual information, such as the handle of the thread, process and user that made the call. And RegNotifyChangeKeyValue is only useful for watching a single, specific value - if you monitor a tree, it doesn't even tell you what changed, only that something matching the filter did. And as with file system changes, if you want to know which thread/process/user made the change, you need to use a driver.