<div dir="ltr">I got the strace output of my non-C binary (I filtered the noise out of the output for you): <div><font face="verdana, arial, helvetica, sans-serif"><span style="font-size:14px;line-height:20px"><br></span></font></div><div><span style="font-family:verdana,arial,helvetica,sans-serif;font-size:14px;line-height:20px">mmap(NULL, 8192, PROT_READ | PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)</span></div><div><br>I also have readelf -l output:</div><div><br></div><div><div>Elf file type is EXEC (Executable file)</div><div>Entry point 0x401311</div><div>There are 7 program headers, starting at offset 64</div><div><br></div><div>Program Headers:</div><div>  Type           Offset             VirtAddr           PhysAddr</div><div>                 FileSiz            MemSiz              Flags  Align</div><div>  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000</div><div>                 0x00000000000db604 0x00000000000db604  R E    1000</div><div>  LOAD           0x00000000000dc1c0 0x00000000004dd1c0 0x00000000004dd1c0</div><div>                 0x0000000000006220 0x00000000000091dc  RW     1000</div><div>  NOTE           0x00000000000001c8 0x00000000004001c8 0x00000000004001c8</div><div>                 0x0000000000000024 0x0000000000000024  R      4</div><div>  GNU_EH_FRAME   0x00000000000d5680 0x00000000004d5680 0x00000000004d5680</div><div>                 0x0000000000005f84 0x0000000000005f84  R      4</div><div>  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000</div><div>                 0x0000000000000000 0x0000000000000000  RWE    0</div><div>  TLS            0x00000000000dc1c0 0x00000000004dd1c0 0x00000000004dd1c0</div><div>                 0x0000000000000100 0x0000000000000100  R      10</div><div>  GNU_RELRO      0x00000000000dc1c0 0x00000000004dd1c0 0x00000000004dd1c0</div><div>                 0x0000000000005e40 0x0000000000005e40  RW     20</div><div><br></div><div> Section to Segment mapping:</div><div>  Segment Sections...</div><div>   00     .note.gnu.build-id .init .text .fini .gcc_except_table .rodata .debug_gdb_scripts .eh_frame .eh_frame_hdr </div><div>   01     .tdata .data.rel.ro.local .<a href="http://data.rel.ro">data.rel.ro</a> .init_array .got .got.plt .data .bss </div><div>   02     .note.gnu.build-id </div><div>   03     .eh_frame_hdr </div><div>   04     </div><div>   05     .tdata </div><div>   06     .tdata .data.rel.ro.local .<a href="http://data.rel.ro">data.rel.ro</a> .init_array .got .got.plt</div><br>Some notes:<br><br>As a test, I changed the non-C binary&#39;s target device file to /dev/zero, and then I could see that the non-C mmap attempt would succeed just fine.<br><br>After further verification and debugging based on guidance from another forum, I have convinced that the vm_flags change must be occuring somewhere in kernel land after control flow has left user land. Now I need to figure out how to use a kernel debugger or kprobes to walk through the execution of mmap callback delegation and see where the flags parameter is being changed.<br><br>I was pointed out to this:<br><a href="http://lxr.free-electrons.com/source/mm/mmap.c#L1312">http://lxr.free-electrons.com/source/mm/mmap.c#L1312</a><br><br>But why would my vm_flags be changed by the kernel? And what can I do to get this to stop? Why is the kernel changing the vm_flags for a non-C binary using my device file, but not for either a C binary using my device file or any type of binary that&#39;s not using my device file?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 12:28 PM, Kenneth Adam Miller <span dir="ltr">&lt;<a href="mailto:kennethadammiller@gmail.com" target="_blank">kennethadammiller@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Jan 14, 2016 at 12:00 PM, Mike Krinkin <span dir="ltr">&lt;<a href="mailto:krinkin.m.u@gmail.com" target="_blank">krinkin.m.u@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, i have a couple of questions to clarify, if you don&#39;t mind<br>
<span><br>
On Thu, Jan 14, 2016 at 11:04:28AM -0500, Kenneth Adam Miller wrote:<br>
&gt; I have a custom drive and userland program pair that I&#39;m using for a very<br>
&gt; special use case at my workplace where we are mapping specific physical<br>
&gt; address ranges into userland memory with a mmap callback. Everything works<br>
&gt; together well with a C userland program that calls into our driver&#39;s ioctl<br>
&gt; and mmap definitions, but for our case we are using an alternative systems<br>
&gt; language just for the userland program.<br>
<br>
</span>So you have userland app written in C, and another not written in C?<br>
The former works well while the latter doesn&#39;t, am i right?<br></blockquote><div><br></div></span><div>Yes, the former works in so much as mmap completes successfully. I&#39;ve verified that the </div><div>parameters are identical in the non-C program. The issue of just using the C only program </div><div>is that the actual implementation of interest is in the non-C program, and that&#39;s because </div><div>that language facilitates other features that are *required* on our end. </div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
&gt; That mmap call is failing (properly<br>
&gt; as we want) out from the driver&#39;s mmap implementation due to the fact that<br>
&gt; the vm_flags have the VM_EXEC flag set. We do not want users to be able to<br>
&gt; map the memory range as executable, so the driver should check for this as<br>
&gt; it does. The issue is in the fact that somewhere between where mmap is<br>
&gt; called and when the parameters are given to the driver, the vma-&gt;vm_flags<br>
&gt; are being set to 255. I&#39;ve manually checked the values being given to the<br>
&gt; mmap call in our non-C binary, and they are *equivalent* in value to that<br>
&gt; of the C program.<br>
<br>
</span>By &quot;manually&quot; do you mean strace? Could you show strace output for<br>
both apps? And also could you show readelf -l output for both binaries?<br></blockquote><div><br></div></span><div>By manually, I mean with a print call just before the mmap call in each of the </div><div>programs. Right now, I&#39;m working on getting a strace output, but I have to run that in qemu.</div><div>To be able to run it in qemu in order to isolate the driver and all from my host, I have to build</div><div>with buildroot. So I&#39;ll email that when I get it, but it&#39;ll be a while.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
&gt;<br>
&gt; My question is, is there anything that can cause the vma-&gt;vm_flags to be<br>
&gt; changed in the trip between when the user land program calls mmap and when<br>
&gt; control is delivered to the mmap callback?<br>
<br>
</span>&gt; _______________________________________________<br>
&gt; Kernelnewbies mailing list<br>
&gt; <a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
&gt; <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>