tag:blogger.com,1999:blog-5351615674355348814.post191188998774084261..comments2023-03-26T00:51:34.258+11:00Comments on DavisDoesDownUnder: Linux syscall, vsyscall, and vDSO... Oh My!Matthttp://www.blogger.com/profile/04709610615390095921noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-5351615674355348814.post-73282574323964430002013-07-18T14:05:28.366+10:002013-07-18T14:05:28.366+10:00Click on my Google plus profile icon. And when yo...Click on my Google plus profile icon. And when you get to the "About" page by my name should have an envelope/email icon. Use that. If it does not work I'll post it here.Matthttps://www.blogger.com/profile/04709610615390095921noreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-9410109854376042372013-07-18T13:51:32.010+10:002013-07-18T13:51:32.010+10:00Thanks for the quick response! No, I am not changi...Thanks for the quick response! No, I am not changing the permissions of the child process. I checked out your other post as well, but I am still clueless as to what is going wrong. <br /><br />Btw, where can I find your email? (Its not there on your blog profile page)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-76703751496553360952013-07-18T11:23:17.213+10:002013-07-18T11:23:17.213+10:00It might be best that we take this offline. Shoot...It might be best that we take this offline. Shoot me an email and we can work on it together. Upon initial consideration, the vdso is read only, so you should be able to read it. You do not change the permissions of the child process do you (presumably not since you can read other portions of its mem)? <br /><br />However, the vdso should be the same for all processes. So, you can read it from any context and make use of the data as you wish. Now, remember that it is not writeable, which kinda prevents you from manipulating it. <br /><br />In the meantime, check out the following article. I have some code in there, which I borrowed from a resource listed. I believe I did modify it a tad from that in [10] above.<br />http://www.linuxjournal.com/content/creating-vdso-colonels-other-chickenMatthttps://www.blogger.com/profile/04709610615390095921noreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-63448223402749564612013-07-18T11:09:59.133+10:002013-07-18T11:09:59.133+10:00Hi Matt,
Very nice article - Thanks. I was wonderi...Hi Matt,<br />Very nice article - Thanks. I was wondering if you can shed some light on a problem that I am facing in examining the vdso. I am trying to read the proc/pid/mem for a child process - I can successfully read most of it, but not the vdso part. Reading the vdso part from /proc/*/mem gives me Input/Output error. Any idea why this might be happening or thoughts on getting it to work?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-53163680069646868422013-05-06T21:14:57.815+10:002013-05-06T21:14:57.815+10:00You can probably find the answer here: http://lwn....You can probably find the answer here: http://lwn.net/Articles/446528/<br /><br />It mentions that the variables in the vsyscall page were moved to a non-executable page, somewhere around kernel 3.1.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-16869143632065894052013-04-03T23:00:39.734+11:002013-04-03T23:00:39.734+11:00Actually it's the default glibc.Actually it's the default glibc.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-5435580125697766862013-04-03T22:41:28.541+11:002013-04-03T22:41:28.541+11:00Interesting. I really don't have much to say....Interesting. I really don't have much to say. Are you perhaps using an alternate libc (e.g. not glibc?). An alternative libc with the combination of a modified/patched kernel might use that unmapped space for some auxiliary purposes. Please keep me posted. Also, feel free to email me directly.Matthttps://www.blogger.com/profile/04709610615390095921noreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-13291115157145160882013-04-03T21:32:41.237+11:002013-04-03T21:32:41.237+11:00Hey Davis,
Thanks for the quick response. T...Hey Davis,<br /> Thanks for the quick response. There are two parts to the above problem 1) The maps/gdb does not show it 2) Only certain kernels use this space. Looking at kernel source has not helped yet, and the space for threadstack looks unlikely because it's just one page, anything above it is unmapped, and below is vsyscall. So is this some book keeping space for the vsyscall itself? But would be nice to know precisely who uses it and why it's not documented anywhere(including maps:)).<br /><br />Thanks. <br /><br /> Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-81537639308889219162013-04-03T08:28:47.799+11:002013-04-03T08:28:47.799+11:00Hi. I do not know the answer to your question, of...Hi. I do not know the answer to your question, off of the top of my head. While it is not reported, it still lies within the userspace of a process. Perhaps it is for threads and holds the room for thread stacks?Matthttps://www.blogger.com/profile/04709610615390095921noreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-74674662105020731752013-04-03T02:56:14.534+11:002013-04-03T02:56:14.534+11:00Hi Davis,
Can you please tell me why in s...Hi Davis,<br /><br /> Can you please tell me why in some of the kernels there is one page exactly above the beginning of vsyscall mapped and accessible. But neither the gdb nor the /proc//maps really reports it. <br /><br />#include <br /><br />int main() {<br />char *p = (char *) (0xffffffffff600000-2);<br />printf("%d\n", *p);<br />return 0;<br />} <br /><br />Running the above simple test case SIGSEGVs only on few kernels one such is 2.6.18-92.el5(rhel 5.8) and on most of the kernels including my desktop(3.2.0-29-generic) it's accessible. But the weird part is even if you step through instruction by instruction in gdb, it reports memory is not accessible but actually it's accessible and either outputs -1 or 0!! Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-81875877342405603002012-03-02T10:30:59.855+11:002012-03-02T10:30:59.855+11:00Hi MK,
Without performing some calculations I cann...Hi MK,<br />Without performing some calculations I cannot say if the speedup you are witnessing is from the switch of vsyscall to vdso. Either way, both vdso and vsyscall avoid the user/kernel context switch. So, in your case, I am a bit interested as to where this speedup is occurring. If possible, I'd compile a basic C program calling gettimeofday(), one for each kernel, and step-through both.Matthttps://www.blogger.com/profile/04709610615390095921noreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-36082641281480301192012-03-01T08:01:20.597+11:002012-03-01T08:01:20.597+11:00Hello,
I came across this great article while try...Hello,<br /><br />I came across this great article while trying to understand something. Maybe you would know about it?<br /><br />I have observed that the time it takes to call gettimeofday has decreased *significantly* (~500 ns to ~20 ns) when I moved from a 2.6.18 system to a 2.6.33 system (similar h/w). <br /><br />2.6.18 uses the vsyscall method while 2.6.33 uses vdso method to make this invocation fast. But, I do not think that this difference can account for such a huge difference in the times.<br /><br />Do you have any insight into what has caused this improvement?<br /><br />Many thanks!MKhttps://www.blogger.com/profile/17435085674059795558noreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-65435839910836270222011-02-20T09:40:24.940+11:002011-02-20T09:40:24.940+11:00Thanks Mitch. In fact, I used to do all my asm wi...Thanks Mitch. In fact, I used to do all my asm with good ole' int 80. Even if your CPU supports the newer syscall/sysenter instruction, you can still use int 80h.Matthttps://www.blogger.com/profile/04709610615390095921noreply@blogger.comtag:blogger.com,1999:blog-5351615674355348814.post-49588243245891050612011-02-20T09:31:28.889+11:002011-02-20T09:31:28.889+11:00There's a bunch of stuff you've mentioned ...There's a bunch of stuff you've mentioned that I've been wondering about for quite some time. I knew about the int 0x80 stuff (hey, I'm old school from when that's all we had) but I didn't know about the rest. I am going to have to come back to this page and read it several times!Anonymoushttps://www.blogger.com/profile/05711651430064455098noreply@blogger.com