Hacker News Reader

Comment by fooker | Hacker News Reader

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.

View on HN

Can 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.

Security and performance are often have different, contradictory needs.

The meltdown+spectre saga showed this for speculative execution. This is no different.

Typically 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.

Note, 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.

Reply on news.ycombinator.com