[PATCH 1/6] msgb: Add msgb_resize_area and msgb_copy

[Neels Hofmeyr]

On Tue, Nov 24, 2015 at 09:40:48AM +0100, Jacob Erlbeck wrote:
> On 19.11.2015 15:34, Neels Hofmeyr wrote:
> > +/*! \brief Copy an msgb.
> > 
> > I'd write just "a" here, not "an". I seem to be the English nitpicker
> > among us ;)
> 
> I do not agree in this case. "msgb" is read em-es-... thus starting with

Ah ok, I see your point. I tend to read "message-bee", starting with a
consonant, so I'd have written "a". Keep the "an", then :)

> > +int msgb_resize_area(struct msgb *msg, uint8_t *area,
> > +			    size_t old_size, size_t new_size)
> > +{
> > +	int rc;
> > +	uint8_t *rest = area + old_size;
> > +	int rest_len = msg->len - old_size - (area - msg->data);
> > +	int delta_size = (int)new_size - (int)old_size;
> > +
> > +	if (area < msg->data || rest > msg->tail)
> > +		MSGB_ABORT(msg, "Sub area is not fully contained in the msg data\n");
> > 
> check for rest < area in addition.

Sounds good.

Actually, msgb's len fields are typed as uint16_t, so I think old_size and
new_size should be uint16_t arguments...?

And then, I think these are also necessary:

- assert rest_len >= 0, which ensures a valid old_size, i.e. short for
  old_size <= (msg->len - (area - msg->data)).

- assert new_size <= (0xffff - (area - msg->data))
  (so that the resulting len is within uint16_t).

It's quite time consuming to figure this out in theory, so maybe we can
just merge this and have a "break msgb contest", rewarding an Osmocom mug
for every msgb API test case that allows arbitrary memory access ;)

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151125/37698038/attachment.bin>