On Thu, Sep 1, 2016 at 2:16 PM, Richard Braun <rbr...@sceen.net> wrote:
>
> Therefore I'm going back to the idea of using a thread pool. If a
> mach_msg call succeeds, good for you, grab the next message. If not,
> at least you're not affecting other users, except maybe through a
> denial of service, the only kind of security issue inevitable with
> a design where servers allocate from their own resources on behalf
> of their clients. That's when you get to things like quotas and
> resource limits.
>
I've implemented this approach in the latest version of netmsg. In
addition to isolating the effects of a blocking mach_msg call, this also
has the advantage of dealing (in the same way) with OOL data backed by a
faulty memory manager that causes the memory access to block indefinitely.
Of course, we really don't want our memory managers stalling indefinitely,
and, to that end, I've implemented the following, very simple, change to
libpager. It just notifies the kernel that it can't handle a particular
memory object request, rather than remaining silent:
--- /home/baccala/src/hurd/libpager/object-init.c 2016-08-03
12:11:39.099553252 -1000
+++ object-init.c 2016-09-07 12:05:24.825456046 -1000
@@ -54,6 +54,8 @@
p->init_head = i;
p->init_tail = i;
#else
+ memory_object_ready (control, p->may_cache, p->copy_strategy);
+ memory_object_destroy (control, EBUSY);
printf ("pager dup init\n");
#endif
goto out;
It's not perfect. It leaks ports, since it never destroys the control and
name ports, but fixing that is not so trivial as just releasing the send
rights, because the kernel will follow up the memory_object_destroy with a
memory_object_terminate that includes the receive rights on those ports.
What this change does do, however, is expose the bug in glibc that I just
opened a bug report on. Once that's dealt with (and the current netmsg
code deals with it), then attempting to exec a remote program using the
standard exec server doesn't hang, but instead produces a "Killed" message
along with a slew of warnings from netmsg.
I consider this progress!
agape
brent
