Re: [Kyle Ackerman] Re: imsg_get_data Question

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.