Re: [Kyle Ackerman] Re: imsg_get_data Question

Theo de Raadt <[email protected]> wrote:

> Kyle Ackerman <[email protected]> wrote:
> 
> > ------- Forwarded Message
> > 
> > From: Kyle Ackerman <[email protected]>
> > To: Florian Obser <[email protected]>
> > Subject: Re: imsg_get_data Question
> > Date: Sun, 16 Aug 2026 12:52:15 -0600
> > 
> > Florian Obser <[email protected]> writes:
> > 
> > > imsg is usually used over a privilege boundary. The sender is supposed
> > > to send exactly len bytes of data. If it fails to do that the receiver
> > > has to assume the sender is compromised and terminate itself.
> > > E.g. (dhcpleased/engine.c):
> > >
> > > case IMSG_CTL_LOG_VERBOSE:
> > > 	if (imsg_get_data(&imsg, &verbose,
> > > 	    sizeof(verbose)) == -1)
> > > 		fatalx("%s: invalid %s", __func__, i2s(type));
> > For more context, there is a current use case in Got where we send over
> > a struct and a string in the same imsg.  I imagined a case where you can
> > do multiple imsg_get_data(3) calls, over predefined lengths, to utilize
> > the rpos and wpos fields to incrementally extract seprate data.
> 
> imsg fails so hard at being an "xdr"... (in sunrpc, this is the
> difference beween the rpc layer, and the xdr layer.  in imsg there is no
> xdr layer, but extraction is done with code, and hopefully agreeable
> code in the sender and receiver, and hopefully sufficient edge case
> handling in the receiver).
> 
> imsg encourages the creation of messages, and extraction of messages (with
> required failure checks), to be done WITH CODE at the point of use in
> functions which are going to act upon the data.  Meaning it tends to be
> in the exact same function that is going to do something with it.
> 
> I continue to conclude that imsg is a huge failure of abstraction, and
> it needs to be completely replaced.  It was fine in original bgpd where
> the message types were extremely well defined, but this pattern should
> never have been been copied elsewhere AND EXTENDED, and it just keeps
> becoming more and more painful.  bgpd did not need a struct + a string.
> imsg could not do it.  

To add a bit more.

imsg is generally used as a private protocol between privsep processes
over a pipe.

Security principles suggest this private protocol should be as simple as
possible.

In the simplest case it could be atomicio write of a struct, and atomicio
read of a struct.  But no, most of those were converted to imsg.

I believe the protocols should be extremely narrowly for the purpose,
very few lines of perfect code.  If a privsep protocol does not need
variable sized objects, remove that code.  If it does not need fd
passing, remove that code.  But the imsg API is becoming more far more
general, and adaptation is being forced upon all existing imsg using
programs.

I think this trend is wrong, and some discoveries (by a UBC group) suggests
that imsg API is too difficult to use 100% correctly.