bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Implementing protected payloads in GNU Mach, mig, and the Hurd


From: Justus Winter
Subject: Implementing protected payloads in GNU Mach, mig, and the Hurd
Date: Fri, 29 Nov 2013 00:56:47 +0100
User-agent: alot/0.3.4

Hi :)

I've been reworking the receiver object lookup in
Hurd/mig/gnumach. I'll briefly sketch the current state of affairs.

Suppose a file is truncated. To do that, a file_set_size message is
sent to some port. The relevant ipc routine is:

routine file_set_size (
        trunc_file: file_t;
        RPT
        new_size: loff_t);

Here, trunc_file is the receiver, its type is file_t. This patch set
optimizes the receiver lookup in the server.

Suppose the receiving server is implemented using libports like most
Hurd components are. Now three lookups take place.

1. In the kernel, matching the sender thread to the receiver.
2. In libports, in either manage_multithread or manage_one_thread.
3. In the in-translator function defined for file_t by setting FILE_INTRANS.

This patch set adds support for protected payloads to GNU Mach, mig
and the Hurd. It adds an kernel call to gnumach to set the payload for
receive rights:

routine mach_port_set_protected_payload(
                task            : ipc_space_t;
                name            : mach_port_name_t;
                payload         : natural_t);

Once this is done for a port, incoming messages will carry the payload
instead of the local port:

--- a/include/mach/message.h
+++ b/include/mach/message.h
@@ -136,7 +136,10 @@ typedef    struct {
     mach_msg_bits_t    msgh_bits;
     mach_msg_size_t    msgh_size;
     mach_port_t                msgh_remote_port;
-    mach_port_t                msgh_local_port;
+    union {
+        mach_port_t    msgh_local_port;
+        unsigned long  msgh_protected_payload;
+    };
     mach_port_seqno_t  msgh_seqno;
     mach_msg_id_t      msgh_id;
 } mach_msg_header_t;

A new mach type MACH_MSG_TYPE_PROTECTED_PAYLOAD is defined to indicate
that the message carries a payload, not a port name. libports is
patched to handle the payloads. This takes care of lookup number 2.

Removing the need for lookup 3 is actually more involved. It requires
changes to mig so that one can specify a payload-aware in-translation
function. Such a function is almost exactly like the port-based
in-translation function, here is a typical one:

--- a/libcons/priv.h
+++ b/libcons/priv.h
@@ -80,6 +80,12 @@ begin_using_notify_port (fs_notify_t port)
   return ports_lookup_port (cons_port_bucket, port, cons_port_class);
 }
 
+static inline cons_notify_t
+begin_using_notify_payload (unsigned long payload)
+{
+  return ports_lookup_payload (cons_port_bucket, payload, cons_port_class);
+}

A thing that we need to take care of at this point is that some server
functions actually expect a port name, not an object. Fortunately this
is easy to cover, we provide an in-translation function for that:

type mach_port_t = MACH_MSG_TYPE_COPY_SEND
        intranpayload: mach_port_t HURD_DEFAULT_PAYLOAD_TO_PORT;

There are some gory details at this point, but I'm confident that all
issues can be dealt with. The kernel and mig parts seem to be feature
complete for my current needs, and I've been running the patched
kernel compiled using the patched mig just fine for the last day or
two on my development machine. An earlier Hurd patch series that did
only address lookup #2 but not #3 did actually boot on my test machine.

The Hurd part is what it is. hello{,-mt} work, so does tmpfs. I broke
rpctrace, libpager, proxy-defpager, ext2fs hangs, bootstrap fails,
exec replies EOPNOTSUPP so I must have broken an lookup there...

The really nice thing about this approach is the smooth upgrade
path. The protected payload code in libports is used only as an
optimization, so if it is run on an older kernel, it will fall back to
the port-based lookup #2 *but* will then store the object's address in
the message. This way, the third lookup is optimized away. It's a
kernel patch that makes Hurd faster on unpatched kernels. It's that
smooth.

But I need a break from this stuff and I wanted to get your
opinions. The code is here for easy access:

http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/log/refs/heads/feature-protected-payload-4

http://darnassus.sceen.net/gitweb/teythoon/mig.git/log/refs/heads/feature-protected-payload-2

http://darnassus.sceen.net/gitweb/teythoon/hurd.git/log/refs/heads/feature-protected-payload-3

I'll spam the list with the patches to get the discussion going :)

Justus


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 
20131128235647.1092.90189@thinkbox.jade-hamburg.de">http://lists.debian.org/20131128235647.1092.90189@thinkbox.jade-hamburg.de




reply via email to

[Prev in Thread] Current Thread [Next in Thread]