Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros

[Thomas Schwinge]

Hi!

On Mon, 06 Jun 2016 09:06:35 +0200, l...@gnu.org (Ludovic 
=?utf-8?Q?Court=C3=A8s?=) wrote:
> Samuel Thibault <samuel.thiba...@gnu.org> skribis:
> > Ludovic Courtès, on Sun 05 Jun 2016 21:53:35 +0200, wrote:
> >> Justus Winter <jus...@gnupg.org> skribis:
> >> > +#define Mach_port_check(NAME)                                           
> >> > \
> >> > +  void _Mach_port_check_##NAME(char *_unused[] __attribute__ 
> >> > ((unused))) \
> >> > +  {                                                                     
> >> > \
> >> > +  if (MACH_PORT_VALID (NAME))                                           
> >> > \
> >> > +    __print_fail_backtrace (#NAME " leaked",                            
> >> > \
> >> > +                            __FILE__, __LINE__, "Port leak detector");  
> >> > \
> >> > +  }                                                                     
> >> > \
> >> > +  char _Mach_port_check_x_##NAME[0]                                     
> >> > \
> >> > +  __attribute__ ((unused, cleanup (_Mach_port_check_##NAME)))

That, basically, is encoding the Mach API's semantic information using C
language constructs (specifically here, GCC extensions, which is OK in
our context, of course).  As noted already, this will require us to touch
a lot of the existing code, to have it use this "new" API, basically.

Conceptually, such an improved API seems totally reasonable to me, and I
have thought about such things before.

I don't remember the details right now, but we also toyed with the idea
of a "rich" Mach port class in context of the "Improve Java on Hurd"
Google Summer of Code 2011 project,
<https://www.gnu.org/software/hurd/user/jkoenig/java.html>.  (Jérémie
Koenig CCed, just in case.)  See "Java bindings for Mach" on that page,
and <https://github.com/jeremie-koenig/hurd-java>.  For example, the Java
variant of Justus' Mach_port_check quoted at the beginning of this email,
<https://github.com/jeremie-koenig/hurd-java/blob/master/mach/MachPort.java>:

        /* Check that the port was deallocated and has no references left at
         * collection time. */
        @Override
        protected final void finalize() {
            if(refCnt > 0) {
                System.err.println(String.format(
                            "MachPort: port name %d was never released", name));
                refCnt = 0;
            }
            if(name != Mach.Port.DEAD) {
                System.err.println(String.format(
                            "MachPort: port %d was never deallocated", name));
                deallocate();
            }
        }

> >> I think writing a GCC plug-in that would automatically add a cleanup
> >> handler to automatic variables of type ‘mach_port_t’ wouldn’t be
> >> unreasonable.
> >
> > I don't enough to be sure, but isn't that the typical work of
> > LocalitySanitizer, precisely?
> 
> Could be!  I’m not familiar with it.

There is no LocalitySanitizer in GCC/LLVM.  ;-)
<https://www.google.com/search?q="LocalitySanitizer";> says 'search -
"LocalitySanitizer" - did not match any documents'.

A compiler plugin certainly is one option to implement this.  I just
wonder how many "special cases" we'll run into, where such a plugin needs
additional information, which then will require something like compiler
pragmas or type/variable/function attributes, telling the compiler plugin
what's going on?

It seems better to me, to keep all that information close together: where
the Mach API is described, the Mach header files, if you will.

The next thought then occurred to me: why not use a programming language
that allows for defining additional types, powerful enough to model the
desired semantics?  For example, if we'd compile the Hurd with a C++
compiler (which, hopefully, will just work -- mostly), could we then
create a mach_port_ta C++ class, wrapping the "primitive" Mach data type,
and teach that one the Mach API semantics?  For example, that a port
right locally "goes away" after move/transfer operations, or that at the
end of any scope any local ports rights must have "gone away" to avoid
leaks.

Both in Justus' C variant, the compiler plugin variant, and the C++
variant, it seems reasonable to assume that the compiler will be able to
optimize away most of such checking code.

So, I don't know what peoples' feelings are about C++, but perhaps that's
worth considering, assuming that we can come up with a concise design of
a mach_port_t class, and others.  I'm sure similar things/designs have
been done in other contexts, where there is a difference between
copy/duplicate/move/transfer operations, for example.  (What does
"assignment" with the "=" operator mean, for example...)


Grüße
 Thomas

signature.asc
Description: PGP signature