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):
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a8a1dc1e33267e0fa2dab...
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 following:
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?
Regards, -- Bob