3 ms·
If it's truly asynchronous, I don't see the issue with IO being decoupled from process lifetime. If you wanted to stop the IO at process death, the mechanism n
by fooker 1mo ago
If it's truly asynchronous, I don't see the issue with IO being decoupled from process lifetime.
If you wanted to stop the IO at process death, the mechanism needed for this would introduce an overhead that would likely slow things down in general.
- eivanov89 1mo agoNote, that this also includes retaining process memory related to the I/O. In my experiment I used regular 4 KiB pages, which is smaller or equal to the I/O block size. However, in case of huge pages only a small fraction can be I/O related. And I suppose, that this small part would pin the whole page, which might have some sensitive information. Still protected, however, but who knows.
- charcircuit 1mo agoCan you explain your thinking? From my understanding of the issue as an extreme example you could have a "write a backdoored .bashrc, then wait 5 minutes" repeated a thousand times queued as async i/o. If malware did this you couldn't just kill the process to stop it. You would have to shutdown the machine. Being able to stop this loop by just killing the process is a cleaner abstraction from my perspective.
- fooker 1mo agoSecurity and performance are often have different, contradictory needs. The meltdown+spectre saga showed this for speculative execution. This is no different.
- charcircuit 1mo agoTypically there is also a latency trade off, so you can choose security and performance while losing latency. Systems should not depend on processes being fast to terminate anyways so making it slower in this case is fine.