5 ms·

I'm trying to figure out what the expected behavior (and fix) should be. Basically the bug is that a external process could posion a processes version of a file

I'm trying to figure out what the expected behavior (and fix) should be. Basically the bug is that a external process could posion a processes version of a file by silently manipulating the file and causeing the file to be reread. Given the requirements that a secondary process should even be able to modify a file that is already open, I guess the expected behavior is that the 1st process's version should remain cached in memory while allowing the on-disk (CoW) version to be updated? While also informing the 1st process of the update and allowing the 1st process to reload/reopen the file if it chooses to do so. If this is the intended/expected behavior, then it follows that pwrite() and other syscalls should inform the kernel and cause prevent the origional cache from being flushed.

saagarjha 8y ago
From what I understand, that seems about right. I don't think the first process's version should necessarily remain in the page cache, but it should not be reread from the (modified) backing filesystem.
nerdponx 8y ago
Am I mistaken in thinking that Windows is immune to this kind of bug? Also, why isn't this a problem in Linux or BSD?
mgoetzke 8y ago
Still don't understand it though. If the bad code is already able to alter the files on disk is it really make a difference whether the data was altered before or after the using code had mapped it into its memory ? Either the file is changed before the process starts, in which case it already gets bad data, or it is altered after in which case it only sees it after experiencing memory pressure. Wouldn't the issue be the change on disk in the first place ?
- Crespyl 8y ago
  Reading the bug report it sounds like it has more to do with the Copy-on-Write behavior. If I've understood correctly, I think it works something like this: A privileged process needs to use some shared-object/library, and the OS loads that file into memory for it. An unprivileged process creates an exact duplicate of the library file and asks the OS to load that into memory. This triggers the copy-on-write system to realize that these are identical, and creates a link between them so that both processes are using the same chunk of memory. The privileged process then doesn't actually use the library for a while, so the OS pages it out of memory, while keeping that copy-on-write link around. This is where the sneaky/buggy part lies, in that it's possible for the unprivileged process to modify its version of the library file without the copy-on-write system being informed of the write (and thus separating the two diverging copies). This is apparently related to some details of how mounting filesystem images works. The next time the privileged process tries to use the library, the OS sees that it has already been paged out, but hey here's this copy-on-write link pointing at this "identical" version over here, and loads the poisoned version into the privileged process.
  - mgoetzke 8y ago
    Thanks for this info. Yeah, this kind of scenario is unacceptable. I did not see that the files are single instanced in memory. Is the overhead for this even worth it ? Two files being loaded that are exactly identical sharing the same ram space (writable too) sounds like overhead for no usable gain. I guess when you are compressing ram anyways they might calculate checksums anyway and thus have the info to coalesce chunks, but it sounds like a really bad choice.
benmmurphy 8y ago
doing this COW stuff with file mapped pages generally must be kind of weird. like normally with a COW page you just mark the page entry as read only and then when the process tries to modify the page you create a copy of the page for that process. the only process that is modified is the process that tried to write to the page. but with file mapped pages this is going to be a bit weird because the processes with a file page mapped MAP_SHARED should see others modifications of a MAP_SHARED page and presumably now when process modifies a file mapped page that is marked read only the kernel now has to update all the other processes to point at this new writable page. i think it is easy to modify the current process's page table, not sure how easy it is to modify other process's view of the page table. though, maybe the kernel wouldn't let you RPC a MAP_SHARED mmap. maybe it would only let you do it with a MAP_PRIVATE mmap.

saagarjha 8y ago

From what I understand, that seems about right. I don't think the first process's version should necessarily remain in the page cache, but it should not be reread from the (modified) backing filesystem.

nerdponx 8y ago

Am I mistaken in thinking that Windows is immune to this kind of bug? Also, why isn't this a problem in Linux or BSD?

mgoetzke 8y ago

Still don't understand it though. If the bad code is already able to alter the files on disk is it really make a difference whether the data was altered before or after the using code had mapped it into its memory ? Either the file is changed before the process starts, in which case it already gets bad data, or it is altered after in which case it only sees it after experiencing memory pressure. Wouldn't the issue be the change on disk in the first place ?

Crespyl 8y ago
Reading the bug report it sounds like it has more to do with the Copy-on-Write behavior. If I've understood correctly, I think it works something like this: A privileged process needs to use some shared-object/library, and the OS loads that file into memory for it. An unprivileged process creates an exact duplicate of the library file and asks the OS to load that into memory. This triggers the copy-on-write system to realize that these are identical, and creates a link between them so that both processes are using the same chunk of memory. The privileged process then doesn't actually use the library for a while, so the OS pages it out of memory, while keeping that copy-on-write link around. This is where the sneaky/buggy part lies, in that it's possible for the unprivileged process to modify its version of the library file without the copy-on-write system being informed of the write (and thus separating the two diverging copies). This is apparently related to some details of how mounting filesystem images works. The next time the privileged process tries to use the library, the OS sees that it has already been paged out, but hey here's this copy-on-write link pointing at this "identical" version over here, and loads the poisoned version into the privileged process.
- mgoetzke 8y ago
  Thanks for this info. Yeah, this kind of scenario is unacceptable. I did not see that the files are single instanced in memory. Is the overhead for this even worth it ? Two files being loaded that are exactly identical sharing the same ram space (writable too) sounds like overhead for no usable gain. I guess when you are compressing ram anyways they might calculate checksums anyway and thus have the info to coalesce chunks, but it sounds like a really bad choice.

benmmurphy 8y ago

doing this COW stuff with file mapped pages generally must be kind of weird. like normally with a COW page you just mark the page entry as read only and then when the process tries to modify the page you create a copy of the page for that process. the only process that is modified is the process that tried to write to the page. but with file mapped pages this is going to be a bit weird because the processes with a file page mapped MAP_SHARED should see others modifications of a MAP_SHARED page and presumably now when process modifies a file mapped page that is marked read only the kernel now has to update all the other processes to point at this new writable page. i think it is easy to modify the current process's page table, not sure how easy it is to modify other process's view of the page table. though, maybe the kernel wouldn't let you RPC a MAP_SHARED mmap. maybe it would only let you do it with a MAP_PRIVATE mmap.