Smalltalk › Squeak › Squeak VM

Alien Callbacks with SELinux enforcing on

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 3 messages Options
Bob Westergaard
Reply | Threaded
Open this post in threaded view
♦
♦
|

Alien Callbacks with SELinux enforcing on

Bob Westergaard
 
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 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
Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Alien Callbacks with SELinux enforcing on

Eliot Miranda-2
 
Hi Bob,

On Oct 29, 2018, at 7:07 PM, Bob Westergaard <[hidden email]> wrote:

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):


I remember vaguely someone having problems with precisely this issue a couple of months ago.  Did you find anything in the vm-dev archives?

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.

One reason for issuing a pull request would be to get the slaves to run tests on at least the build Linux flavour.  I’m not at all familiar with the details so I could be blown my smoke.  Can anyone tell me, when github says “all tests have passed” for a pull request, what tests have been run and/or how to look at the logs?  We should include FFI tests here if at all possible.


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

When I wrote the code I chose valloc (autocorrect: ballot) on a cursory reading of the man page and it being a simpler invocation than the mmap call above.  Given that it’s a library function, using mmap could well be lighter weight and hence preferable. But if valloc doesn’t always work then using mmap is I suppose inevitable. Please feel free to submit a rewrite (I’d give you write permission to opensmalltalk) as a patch or pull request, as you see fit.

Adding a comment that mmap has been chosen over valloc cuz on at least one Linux system it didn’t work is useful history.

Thanks!!

Regards,
-- Bob
Ben Coman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Alien Callbacks with SELinux enforcing on

Ben Coman
 
On Tue, 30 Oct 2018 at 18:44, Eliot Miranda <[hidden email]> wrote:
 
 Can anyone tell me, when github says “all tests have passed” for a pull request, what tests have been run and/or how to look at the logs?  We should include FFI tests here if at all possible.

click "1"....

image.png

As best I understand it its that both Appveyor and Travis builds are green.
Clicking "2" to drill into Travis, all its jobs are green except "allow_failures" defined in https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.travis.yml
Clicking for example on the first job "3"...

image.png

to view that job's particular log,  then click on the tiny sideways arrow "4" to expand "Testing project..."
image.png

with I presume tests to be run defined here... 


and I'd guess appveyor was similar.

cheers -ben
Free forum by Nabble Edit this page