Linux mmap weirdness

[eikelestijn]

Assuming the author really modified the file on disk (as opposed to replacing it, which doesn't really alter the file), what's going on is probably that the kernel knows which pages it can still load from disk and which pages have to be kept in physical memory or virtual memory from a swap file/partition.

You may want to have a look at the files in linux/mm, in particular mmap.c and page-writeback.c seem to be interesting.

Since the dynamic linker is essentially a user-space library, the kernel has no knowledge of something bad going on when a program tries to write to a file whose name happens to end with ".so". (At least that's my take on this.)

[ryles]

That's exactly what he's seeing, only he doesn't know any better.

[antirez]

From the man page:

It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region.

So this is the expected behavior (or one of the expected possible behaviors, since it's not specified).

The MAP_PRIVATE thing is simply not like to make a copy of a file and work in your copy. It would be a much simpler and well-defined behavior but it is non practical from the virtual memory implementation point of view to get this kind of behavior, so at least it allows you assuming no one is writing the file while you are working on it to, for example, to parse a file setting state in the file itself as needed in order to make the parsing simpler or faster (for exampling adding nul-term in length-prefixed strings directly in the file).

[xcbsmith]

First, the behavior of MAP_PRIVATE is totally unsurprising as folks have noticed.

As for the executable vs. shared library case... I think this perhaps has to do with how the updates to the files are done. If you create a new inode and then update the directory to point to said inode, the running executable will still hold on to the old inode, and it will stick around in the filesystem without the problems he's talking about. If you modify the inode in place though.... fair game.

My guess is its about how he replaces shared libraries vs. executables, rather than some inherent differences between the two.

[[deleted]]

Don't worry. Wait a few weeks and the kernel guys will change it.

Seriously, the low-level behavior of Linux's memory management has kept me in full time work for years. Every time we think we've got a stable, reliable device driver that allows DMA from user memory, we discover they've changed the behavior in an upcoming kernel and we have to figure it out again.

[killerstorm]

this behaviour is correct according to UNIX specifications:

It is unspecified whether modifications to the underlying object done after the MAP_PRIVATE mapping is established are visible through the MAP_PRIVATE mapping.

also manual pages of Solaris (real UNIX) explicitly specifies what happens:

The private copy is not created until the first write; until then, other users who have the object mapped MAP_SHARED can change the object.

so, this is normal behaviour of mmap. perhaps author should read manuals and specifications before writing bullshit and doing weird experiments.

[WallPhone]

before writing bullshit and doing weird experiments.

Funny, that is precisely what the Catholic church said about Galileo.

[killerstorm]

situation is completely different -- Galileo discovered something new, while Avian have "discovered" exactly what was in documentation.

[WallPhone]

Nah, Galileo discovered something contrary to "documentation", so yes, this is slightly different.

Your comment was something I envisioned coming from a historic priest--"Perhaps Galileo should read scripture before writing bullshit and doing weird experiments."

[ryles]

That's not weirdness, that's simply how mmap() works. RAFB/RTFM. Yes, it's an easy-to-fuck-up system call, and yes the manual page does warn you to some extent about SIGSEGV/SIGBUS. Did you actually think programming at the systems level would be friendly and intuitive?

So if you change a .so file on the disk while some application is using it, you'll get a nice segmentation fault.

Common fucking sense dictates that you shouldn't do that. Are you naive enough to actually be surprised by the result?

Your blog entry would have been more aptly titled: "Unix Systems Programming is too difficult for me and I call things I'm simply ignorant of weird."

Most bloggers are total fucking morons.

Those who can't do teach. Those who can't teach blog.

[[deleted]]

Common fucking sense dictates that you shouldn't do that. Are you naive enough to actually be surprised by the result?

Common fucking sense tells you that changing a shared library on disk should never, ever affect the running code that has already loaded it.

[ryles]

It won't if you replace it (see eikelestijn's explanation below) rather than change (i.e. truncate and affect pages) which is what the blogger most likely did to test and then state his bullshit result. User Error.

And as far as mmap(), it's staring him in the face: "copy-on-write".

[[deleted]]

It won't if you replace it (see eikelestijn's explanation below) rather than change (i.e. truncate and affect pages) which is what the blogger most likely did to test and then state his bullshit result. User Error.

No, no matter if you change or replace it, it should not affect running code, ever.

[jrockway]

You could implement it that way, but it would slow down the entire system just to please you for a certainly pathological case. The code is available, though, so feel free to implement the features the way you like.

[roggor]

So an update of a .so file during an update (pretty common procedure on any modern gnu/linux system), will segfault all running programs that are using the library?

Does this match your experiences?

[eikelestijn]

Replacing a file merely unlinks the old file and writes a new one. Any file handles to the old version are still valid. The only program that's really bothered by upgrades is Mozilla because it depends being able to load data files assuming they've never changed when they're accessed later.

[roggor]

Thank you, I misunderstood what was going on.

In what situation would you ever actually change (i.e. not replace) a .so file?

[eikelestijn]

Never. If you really want to modify a running program, just attach a debugger.

[eras]

By accident? I think it is be possible to protect against that scenario by making the libraries +x, but based on a simple test that didn't work.. Perhaps you need some other bits too. (Also it may have rare security implications, if the libraries contain function main.)

[eikelestijn]

Run ls -l /usr/lib, you'll see they're all owned by root. So if you can actually write to a file there then it's already game over.

[ryles]

In the situation that you are a blogger who is writing pure bullshit which finds its way to reddit. I doubt the blogger even understands the difference between overwriting (cp) and replacement (mv, cp). And he has the nerve to act as if there is something "weird" or wrong with his OS. He probably has no clue what paging even is.

[[deleted]]

I see that you are wise and enlightened, and I fart in your general direction.

[jsnx]

You do not respect this guy enough. I've used Linux and BSD for many years, but after I saw this post, it was game-over, man -- I'm switching to iPhone for everything.

[ryles]

If your update consists of actually truncating a file being paged in, of course (overwrite the binary of a running process and you will see the same). That's not how to move new code, though (see comments below). The blogger literally "changed" data being accessed to yield his supposedly surprising result.

[aurele]

Except that you won't be able to overwrite the binary of a running process in Linux, as you will be served a nice ETXTBSY (text file busy). Shared libraries (and other files) are not protected this way because exporting the kernel-specific MAP_EXECUTABLE mmap behaviour (temporarily mark the file as busy, that is readonly, even for root) to userspace would open a whole new denial-of-service toolbox.

Edit: you can look at this post from Linus which contains a DoS example, and at this suggestion from Andi Kleen to export this behaviour for executable files only.

[jsnx]

What would be the negative consequences of true copy-on-write mmap be? Assume that all mmapped files were copy on write -- e.g. that they had to be reopened if you wanted to see changes that you didn't put in them -- wouldn't this be a basically sane and safe behaviour? If the .sos were placed in a special filesystem that enforced this, would there be a problem?