<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 12:00 PM, Mike Krinkin <span dir="ltr"><<a href="mailto:krinkin.m.u@gmail.com" target="_blank">krinkin.m.u@gmail.com</a>></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't mind<br>
<span class=""><br>
On Thu, Jan 14, 2016 at 11:04:28AM -0500, Kenneth Adam Miller wrote:<br>
> I have a custom drive and userland program pair that I'm using for a very<br>
> special use case at my workplace where we are mapping specific physical<br>
> address ranges into userland memory with a mmap callback. Everything works<br>
> together well with a C userland program that calls into our driver's ioctl<br>
> and mmap definitions, but for our case we are using an alternative systems<br>
> 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't, am i right?<br></blockquote><div><br></div><div>Yes, the former works in so much as mmap completes successfully. I'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's because </div><div>that language facilitates other features that are *required* on our end. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> That mmap call is failing (properly<br>
> as we want) out from the driver's mmap implementation due to the fact that<br>
> the vm_flags have the VM_EXEC flag set. We do not want users to be able to<br>
> map the memory range as executable, so the driver should check for this as<br>
> it does. The issue is in the fact that somewhere between where mmap is<br>
> called and when the parameters are given to the driver, the vma->vm_flags<br>
> are being set to 255. I've manually checked the values being given to the<br>
> mmap call in our non-C binary, and they are *equivalent* in value to that<br>
> of the C program.<br>
<br>
</span>By "manually" 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><div>By manually, I mean with a print call just before the mmap call in each of the </div><div>programs. Right now, I'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'll email that when I get it, but it'll be a while.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> My question is, is there anything that can cause the vma->vm_flags to be<br>
> changed in the trip between when the user land program calls mmap and when<br>
> control is delivered to the mmap callback?<br>
<br>
</span>> _______________________________________________<br>
> Kernelnewbies mailing list<br>
> <a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
> <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br>
</blockquote></div><br></div></div>