Spuriously failing mprotect() on ppc64/ppc64le

[Gustavo Luiz Duarte]

On 10/01/2014 08:03 PM, Jerry James wrote:
> Greetings,
>
> I maintain the gcl package for Fedora.  Upstream recently announced
> support for both ppc64 and ppc64le, so I attempted a build.  However,
> the build is failing on an mprotect() call that looks, to me, like it
> ought to succeed.  This is not happening on any other architecture, so
> it is either something in the ppc64-specific gcl code, or some quirk of
> Fedora ppc64 systems.  Here is an example build, with lots of debug
> prints added by yours truly:
> http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2132156
>
> In this case, it is the ppc64le build that failed, but it is the ppc64
> build just as often.  We're in a race to see which one can die first.
>
> Here's why I think the mprotect() should have succeeded.  Near the
> bottom of build.log, you'll see a line that reads:
>
> mprotect failure: 0x1470000 65536 7: Permission denied
>
> ... meaning that we called mprotect(0x1470000, 65536, PROT_READ |
> PROT_WRITE | PROT_EXEC), it returned -1 to indicate failure, and errno
> == EACCES.  Above that is the contents of /proc/<pid>/smaps immediately
> after the failing mprotect() call.  If you dig through that, you can
> find the relevant memory region:
>
> 01210000-19b2f0000 rw-p 00000000 00:00 0
> [heap]
> Size:            6718336 kB
> Rss:                5440 kB
> Pss:                5440 kB
> Shared_Clean:          0 kB
> Shared_Dirty:          0 kB
> Private_Clean:         0 kB
> Private_Dirty:      5440 kB
> Referenced:         5440 kB
> Anonymous:          5440 kB
> AnonHugePages:         0 kB
> Swap:                  0 kB
> KernelPageSize:       64 kB
> MMUPageSize:          64 kB
> Locked:                0 kB
> VmFlags: rd wr mr mw me ac
>
> As we can see from VmFlags, this memory region has the may-read,
> may-write, and may-execute flags set, so there is no problem there.  The
> koji builders have SELinux turned off (verified by running
> selinuxenabled at the top of %build; see the message "SELinux is off.
> Smooth sailing ahead."), so thjis is not an SELinux denial.
Well, the koji builds are done in a chroot environment. I guess that is why you see it disabled in the build log, even if it is enabled in the builder. Could someone with access please confirm the koji builders have selinux enabled?

>
> Can anybody think of any reason why that mprotect() call would have
> failed?  Note that lots of similar mprotect() calls succeeded before
> this one failed.
I guess this is indeed a selinux-related issue. I just tried building gcl on a ppc64le VM. It builds fine when selinux is disabled and fails when selinux is enabled with the same error messages seen in the koji build.

gcl seems to have a workaround to support selinux that relies on READ_IMPLIES_EXEC: http://lists.gnu.org/archive/html/gcl-devel/2014-08/msg00014.html
But looks like READ_IMPLIES_EXEC is not supported on ppc64 or ppc64le... it is always false.

Sorry for the delay... I had to dig some info to respond and the Alpha release is taking a lot of our time.

[]'s
Gustavo Luiz Duarte
>
> Thanks for any suggestions you can give.  Regards,
> -- 
> Jerry James
> http://www.jamezone.org/
>
>
> _______________________________________________
> ppc mailing list
> ppc at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ppc
>