User: Password:
|
|
Subscribe / Log in / New account

msync() and subtle behavioral tweaks

msync() and subtle behavioral tweaks

Posted Jun 21, 2012 19:41 UTC (Thu) by Yorick (subscriber, #19241)
In reply to: msync() and subtle behavioral tweaks by cmccabe
Parent article: msync() and subtle behavioral tweaks

Maybe. There is no guarantee that write(2) from an invalid address wouldn't cause a SIGSEGV instead of returning EFAULT. I could be mistaken, but I believe Linux has actually behaved that way before. msync(2) seems to be more tolerant in general.

Another interesting use of libunwind is for profiling, for which performance is attractive. (Yes, there are alternatives, but libunwind is fairly portable.)


(Log in to post comments)

msync() and subtle behavioral tweaks

Posted Jun 21, 2012 21:15 UTC (Thu) by cmccabe (guest, #60281) [Link]

> Maybe. There is no guarantee that write(2) from an invalid address
> wouldn't cause a SIGSEGV instead of returning EFAULT. I could be mistaken,
> but I believe Linux has actually behaved that way before. msync(2) seems
> to be more tolerant in general.

I'm really curious why you think this. It seems totally bogus to me: the kernel is the one doing the address space checking, not userspace. You would need to add extra code to get the weird and (I think) non-POSIX behavior of delivering a signal to userspace. What gave you the idea that a signal might be delivered?

msync() and subtle behavioral tweaks

Posted Jun 21, 2012 22:03 UTC (Thu) by Yorick (subscriber, #19241) [Link]

I may have misunderstood it entirely, but I was under the impression from old discussions on linux-kernel (that I wish I could find now—sorry) that Posix actually would allow this. Consider an implementation that implements all or parts of write() in user space, for instance.

You would then rightly ask why msync() would be exempt from such a behaviour, and to that I have no good answer. I have seen that syscall being used for this purpose (address checking) in a variety of places, however, misguided or not.

msync() and subtle behavioral tweaks

Posted Jun 22, 2012 3:40 UTC (Fri) by cmccabe (guest, #60281) [Link]

I think glusterfs has a shim library that will intercept some calls to glibc and interpose its own functions. So you might call write() and end up getting a userspace version. So I guess it's not outside the realm of possibility. Of course, glusterfs could theoretically intercept msync as well-- I don't know if their shim library does or not.

I would guess that the people using msync to check whether an address is valid are using it more because it doesn't require you to have any open file descriptors, than because they're being "careful." In fact, it's not even clear according to the man page that you can use msync on memory that wasn't allocated with mmap. I really have no idea what msync is "supposed" to do on memory allocated with brk, for example. So it's just another case of people relying on some pretty hairy implementation details.

As far as I can see, your best bet for checking address validity probably is "mincore." It definitely doesn't make any sense for a shim library to intercept that function.

msync() and subtle behavioral tweaks

Posted Jun 22, 2012 8:40 UTC (Fri) by nix (subscriber, #2304) [Link]

Anyone intercepting relatively-bare syscalls and converting them into library functions like that had better trap SIGSEGV during the call and convert it into an -EFAULT return. It's not like that's terribly hard (though it does require flipping signal dispositions twice, that's fast as syscalls go).

EFAULT vs SIGSEGV on write()

Posted Jun 22, 2012 17:59 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Anyone intercepting relatively-bare syscalls and converting them into library functions like that had better trap SIGSEGV during the call and convert it into an -EFAULT return.

But do the standards or conventional architecture really call for that? I don't think the POSIX definition of write() uses the word "kernel" and I believe the general understanding for any library is that if you pass an invalid address to a subroutine, it might generate a SIGSEGV.

Or are you just making a practicality argument, since people might be depending on EFAULT. I think it would be a pretty unusual program that passes invalid addresses to write() when the program isn't broken.

EFAULT vs SIGSEGV on write()

Posted Jun 22, 2012 23:48 UTC (Fri) by nix (subscriber, #2304) [Link]

It's practicality. If you're trying to transparently, replace a function that normally EFAULTs on events that would cause userspace to SIGSEGV, it behooves you to behave the same way, lest you break some weird program that really depends on this. (I wrote one once. It does happen.)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds