[Vm-dev] Alien Callbacks with SELinux enforcing on

Bob Westergaard bwestergaard at gmail.com
Tue Oct 30 02:07:23 UTC 2018

Hi Everybody,

I'm wondering if anyone has encountered problems with having SELinux
enabled and executing C callbacks with the VMs (Alien class>>#exampleCqsort
should demonstrate this).   From what I have seen, this will fail when the
thunk is being set with execute permissions in allocateExecutablePage()
(here is the relevant line in the 32-bit VM callback source, the same
applies to the 64-bit code):


One workaround is to set SELinux to be permissive or disabled (edit
/etc/selinux/config and reboot).   Another solution is to look at one of
the system or audit log messages which should provide some instructions
with what you can do (it should suggest to set execheap to true or create a
policy file from audit2allow from the denial and install it with semodule).

However, it seems to me that this should work without having to do any of
that.  In order to have reached this point where the callback thunk was
being created the VM has already allocated and marked memory as executable
for the JIT, so the process has permissions to at least set execute
permissions on memory allocated with mmap().

In allocateExecutablePage() if I change vmalloc() to be mmap() like the

    if (!(mem = mmap(0, pagesize, PROT_READ | PROT_WRITE, MAP_ANON |
MAP_PRIVATE, -1, 0)))

The callbacks appear to work again with selinux enabled (it might make
sense to set the execute bits at allocation time and ditch mprotect() but I
was lazy and opted for a cut and paste from where mmap() is used
elsewhere).  My testing of this has been very minimal, so I'm reluctant to
make a pull request.  Plus, I am fairly certain that I can get away with
making SELinux disabled/permissive or use a policy for the process so that
is how I'll likely deal with it.  Nonetheless, it seemed like it was worth
an email to the list.

Is there any reason to still use valloc() used here instead of mmap()?   Or
is there something obvious I am missing here?

-- Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181029/b2e596d0/attachment.html>

More information about the Vm-dev mailing list