Spuriously failing mprotect() on ppc64/ppc64le

[Peter Robinson]

>> 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?

It is not enabled on the builders across all architectures. It's
currently not supported in the builders.

>> 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.

I'm not convinced as selinux isn't supported for koji/mock on builders.

> 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
>>
>
> _______________________________________________
> ppc mailing list
> ppc at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ppc