4 ms·
I don't think that (3) is true.
by staticassertion 5y ago
I don't think that (3) is true.
- dijit 5y agoHow would you implement such a change? Considering that you have: A) some list of allowed applications/programs B) a run of this check on every syscall C) to be faster than a TLB flush
- staticassertion 5y agoI don't know but I can't imagine a highly predictable branch being slower than a TLB flush.
- dijit 5y agoWell consider the fact that checking a table of “ok” programs is a branch and a lookup in of itself.
- staticassertion 5y agoYeah that should be really fast, still. Programs could also opt to just tell the OS "hey don't check this system call from me", on each system call, avoiding any lookup. The impact of TLB flushing, not just the cost of the flush, is really significant - it's going to take a lot of work to be as expensive within the syscall path.
- saati 5y agoWhat would stop malware telling the os to not check it?
- binarybanana 5y agoNothing, but that only makes reading the malware's memory possible with these exploits. That malware won't be able to access memory of some other process, if that other process is using those flags itself. Edit: For that to work that flag would have to work on the context switch level. So every time you switch away from a sensitive process, flush all buffers and whatever else, then switch. This also requires the kernel itself to enable mitigations as necessary when it touches encryption keys before switching back to user space.
- staticassertion 5y agoThat assumes that the malware can already have arbitrary control over system calls, at which point spectre isn't the issue.
- carl_dr 5y agoIt would be a branch, but surely it would be a flag on the process struct set when the process started, rather than a lookup each time.