From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ZksqSmCj; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id E17915A004E for ; Mon, 03 Feb 2025 11:26:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738578416; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Edqd18RTgRRJXUgZj1IjOt3SROJft4f6rRHORmN+Rd0=; b=ZksqSmCjxaui7+sbnwjDIpqprE8pP/dWeRfjMvWWrCzzBBtFvtmyI/WGVTGHFNeTaZu1Qi lECqlz5V+gSWHUOWfQWPL2SVfqlLUn6NnTJX4g2PFL1Fs51SFxuNbSTJpwh3+yGk+U0zCt uCza4AxFw9zHNPgMMT93/5RqV2lrAzQ= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-325-voVrdG0oNcGbh9mJG39RTQ-1; Mon, 03 Feb 2025 05:26:54 -0500 X-MC-Unique: voVrdG0oNcGbh9mJG39RTQ-1 X-Mimecast-MFC-AGG-ID: voVrdG0oNcGbh9mJG39RTQ Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-38639b4f19cso2361337f8f.0 for ; Mon, 03 Feb 2025 02:26:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738578414; x=1739183214; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Edqd18RTgRRJXUgZj1IjOt3SROJft4f6rRHORmN+Rd0=; b=YBuIke3UIyb2MR561uvxVC+s+qPDH4BGPcqDskvrv5Rzck4Ec8XVWoxOSusObTGvWc qwjWJ58NipmXa8LMMNApI4FmTvE2ZmQKSPAvTXck9FVvmZqzAvrB4W9Ae9XcG+2g57rw Wk4bvJ5AYKFM4GySUkyLPEz/98QxDqxkH6vVz/WPb6zJ96w4txxcj5vf8dZeeqRltveZ Rc5p9OP/XatCOPXGdw1D/AV42nxaANPAQ1vmgzgAQxJZNbeKTjbFwjG8uo1zthxte4WN OLKLGyUi17GMUcHCTNErbUgdktjOscrU0huYYtud/NUAJ+XYjQNfaMHneMyOcmdwatU6 0jpw== X-Gm-Message-State: AOJu0YxTFyWRsovaTssC9NAitth7zt1aGZ8Mpo3KjYNViSJ8TmNowLp7 b2Wha46J3TO+w32gEopGDfrQNK6OXa5QzIAE+2ZcXTUHhkrlRRBnHf+GXOWm/wBULpH572/djj7 +/xSd7pGlCAyWkusp1Pg2OXlGtwB217EZ5SWOZqDC/dUvAYyN6Fsa51A5HZfN48tJjmed9+DP8r YYQFPdWLrOL3BytCxERc1giW2H X-Gm-Gg: ASbGncvXwQ/Gk+5rhNq8oST9Tpt7Hyy3f4TqV2XPBlNalvgTt6u0SGNCFIEuBCn6ppG hS3HvZgDTXwX3IdNOgUCzCRWqHntp6gi5mF3NHu5SJytj9SHaOINGVk+I4gD4MShsTo1TksnNqT gtM9ngwxYogAPyI0xOyLay X-Received: by 2002:a05:6000:18a9:b0:385:f66a:4271 with SMTP id ffacd0b85a97d-38c519399bfmr17274991f8f.4.1738578413629; Mon, 03 Feb 2025 02:26:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IEW2isjbkfGCt8xp9b3BX42eKUFXP2NhMnu+Mg6MGsvxRM08EGZG9/M2ld2kXE02cc9OI5vszsAXVAO2EOuBoQ= X-Received: by 2002:a05:6000:18a9:b0:385:f66a:4271 with SMTP id ffacd0b85a97d-38c519399bfmr17274964f8f.4.1738578413237; Mon, 03 Feb 2025 02:26:53 -0800 (PST) MIME-Version: 1.0 References: <20250131145329.1835558-1-ellorent@redhat.com> <20250201141330.59af1324@elisabeth> In-Reply-To: <20250201141330.59af1324@elisabeth> From: Enrique Llorente Pastora Date: Mon, 3 Feb 2025 11:26:42 +0100 X-Gm-Features: AWEUYZluT42W0XIQk3gDQoN62GMovoG-ctIOg_MnoM815HNX8UOjrUxKIUIMnoo Message-ID: Subject: Re: [PATCH] dhcp: Don't re-use request message for reply To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Gzqpp1x3pTJZXq-BWHUe6tIV6nQFKcY9NWGkXQty5KA_1738578414 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: GF4Z7IXEECT5CSLR6AVOZ3TB2U73QAVB X-Message-ID-Hash: GF4Z7IXEECT5CSLR6AVOZ3TB2U73QAVB X-MailFrom: ellorent@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sat, Feb 1, 2025 at 2:13=E2=80=AFPM Stefano Brivio = wrote: > > On Fri, 31 Jan 2025 15:53:29 +0100 > Enrique Llorente wrote: > > > The logic composing the DHCP reply message is reusing the request > > message to compose the it, this kind be problematic from a security > > Does "be problematic" imply "would be ... once we add longer options"? > > > context and may break the functionality. > > Which one? This is important to know for distribution maintainers and, > ultimately, users. > > As far as I know it's all fine until now, the problem would arise in > your next patch, so perhaps state that. > > The real reason why we need this is that we want to have a given, fixed > size for the option field (308) so that we can easily check we don't > exceed it once we start writing the FQDN in it. > > > This change create a new reply message and fill it in with proper field= s > > from request adding on top the generated opetions. > > s/opetions/options/ > > > > > Signed-off-by: Enrique Llorente > > --- > > dhcp.c | 55 ++++++++++++++++++++++++++++++++++++++----------------- > > 1 file changed, 38 insertions(+), 17 deletions(-) > > > > diff --git a/dhcp.c b/dhcp.c > > index d8515aa..d8ff330 100644 > > --- a/dhcp.c > > +++ b/dhcp.c > > @@ -142,17 +142,36 @@ static void fill_one(struct msg *m, int o, int *o= ffset) > > } > > > > /** > > - * fill() - Fill options in message > > - * @m: Message to fill > > + * fill() - Fill fields and options in response message > > On one hand, this fits with a function that's called "fill()". On the > other hand, I would have a slight preference to keep this in dhcp() > because dhcp() is a comprehensive summary (albeit a bit long) of what > we're doing. > > Is there a particular reason why you moved non-option field assignments > to here? The original fill() function do set some non options fields m->op =3D BOOTREPLY; m->secs =3D 0; That was my motivation to add the rest of them. What do you think about doing the opposite and moving op and secs out of fill next to the rest of options ? The place would be just after parsing request with "packet_get(p, 0, offset, offsetof(struct msg, o), &opt_len);" Something like: m =3D packet_get(p, 0, offset, offsetof(struct msg, o), &opt_len)= ; if (!m || mlen !=3D ntohs(uh->len) - sizeof(*uh) || mlen < offsetof(struct msg, o) || m->op !=3D BOOTREQUEST) return -1; reply.op =3D BOOTREPLY; reply.htype =3D m->htype; reply.hlen =3D m->hlen; reply.hops =3D 0; reply.xid =3D m->xid; reply.secs =3D 0; reply.flags =3D m->flags; reply.ciaddr =3D m->ciaddr; reply.yiaddr =3D c->ip4.addr; reply.siaddr =3D 0; reply.giaddr =3D m->giaddr; memcpy(&reply.chaddr, m->chaddr, sizeof(reply.chaddr)); memset(&reply.sname, 0, sizeof(reply.sname)); memset(&reply.file, 0, sizeof(reply.file)); reply.magic =3D m->magic; > > > + * @c: Execution context to copy from > > + * @req: Request message to copy from > > + * @resp: Response Message to write to > > s/Message/message/ > > > * > > * Return: current size of options field > > */ > > -static int fill(struct msg *m) > > +static int fill(const struct ctx *c, struct msg const* req, > > Coding style (assuming you need to change this). > > > + struct msg *resp) > > { > > int i, o, offset =3D 0; > > > > - m->op =3D BOOTREPLY; > > - m->secs =3D 0; > > + resp->op =3D BOOTREPLY; > > + resp->secs =3D 0; > > + resp->hops =3D 0; // We are not a RELAY agent > > Coding style. > > Inconsistency between detail of messages. By this metric, the one above > should also say "We reply FAST" and the one below "This is OLD". > > I don't think these comments really add anything. > > > + memset(&resp->sname, 0, sizeof(resp->sname)); > > + memset(&resp->file, 0, sizeof(resp->file)); > > + resp->yiaddr =3D c->ip4.addr; > > + > > + > > Excess newline. > > > + /* Copy these fields from request */ > > Also rather obvious, plus it would be problematic along with my > suggestion below about having the fields in order. > > > + memcpy(&resp->chaddr, req->chaddr, sizeof(resp->chaddr)); > > + resp->htype =3D req->htype; > > These look like a table, the 'resp' assignments above don't. > > > + resp->hlen =3D req->hlen; > > + resp->xid =3D req->xid; > > + resp->flags =3D req->flags; > > + resp->ciaddr =3D req->ciaddr; > > + resp->siaddr =3D req->siaddr; /* TODO server ip ? */ > > This needs to be 0. The issue is pre-existing, but as you're already > doing this... > > > + resp->giaddr =3D req->giaddr; > > + resp->magic =3D req->magic; > > Could we have *all* those in order? If one is familiar with the > standard (or is reading it), it's easier to follow and find things. > > > for (o =3D 0; o < 255; o++) > > opts[o].sent =3D 0; > > @@ -162,24 +181,24 @@ static int fill(struct msg *m) > > * Put it there explicitly, unless requested via option 55. > > */ > > if (opts[55].clen > 0 && !memchr(opts[55].c, 53, opts[55].clen)) > > - fill_one(m, 53, &offset); > > + fill_one(resp, 53, &offset); > > > > for (i =3D 0; i < opts[55].clen; i++) { > > o =3D opts[55].c[i]; > > if (opts[o].slen !=3D -1) > > - fill_one(m, o, &offset); > > + fill_one(resp, o, &offset); > > } > > > > for (o =3D 0; o < 255; o++) { > > if (opts[o].slen !=3D -1 && !opts[o].sent) > > - fill_one(m, o, &offset); > > + fill_one(resp, o, &offset); > > } > > > > - m->o[offset++] =3D 255; > > - m->o[offset++] =3D 0; > > + resp->o[offset++] =3D 255; > > + resp->o[offset++] =3D 0; > > > > if (offset < OPT_MIN) { > > - memset(&m->o[offset], 0, OPT_MIN - offset); > > + memset(&resp->o[offset], 0, OPT_MIN - offset); > > offset =3D OPT_MIN; > > } > > > > @@ -291,8 +310,9 @@ int dhcp(const struct ctx *c, const struct pool *p) > > const struct ethhdr *eh; > > const struct iphdr *iph; > > const struct udphdr *uh; > > + struct msg const *m; > > Look at the line just above. > > > + struct msg resp; > > unsigned int i; > > - struct msg *m; > > > > eh =3D packet_get(p, 0, offset, sizeof(*eh), NULL); > > offset +=3D sizeof(*eh); > > @@ -321,6 +341,7 @@ int dhcp(const struct ctx *c, const struct pool *p) > > m->op !=3D BOOTREQUEST) > > return -1; > > > > + > > Stray change. > > > offset +=3D offsetof(struct msg, o); > > > > for (i =3D 0; i < ARRAY_SIZE(opts); i++) > > @@ -364,7 +385,6 @@ int dhcp(const struct ctx *c, const struct pool *p) > > > > info(" from %s", eth_ntop(m->chaddr, macstr, sizeof(macstr))); > > > > - m->yiaddr =3D c->ip4.addr; > > mask.s_addr =3D htonl(0xffffffff << (32 - c->ip4.prefix_len)); > > memcpy(opts[1].s, &mask, sizeof(mask)); > > memcpy(opts[3].s, &c->ip4.guest_gw, sizeof(c->ip4.guest_gw))= ; > > @@ -399,16 +419,17 @@ int dhcp(const struct ctx *c, const struct pool *= p) > > opts[6].slen =3D -1; > > > > if (!c->no_dhcp_dns_search) > > - opt_set_dns_search(c, sizeof(m->o)); > > + opt_set_dns_search(c, sizeof(resp.o)); > > + > > Stray extra newline. > > > > > - dlen =3D offsetof(struct msg, o) + fill(m); > > + dlen =3D offsetof(struct msg, o) + fill(c, m, &resp); > > > > if (m->flags & FLAG_BROADCAST) > > dst =3D in4addr_broadcast; > > else > > dst =3D c->ip4.addr; > > - > > Stray change. > > > - tap_udp4_send(c, c->ip4.our_tap_addr, 67, dst, 68, m, dlen); > > + tap_udp4_send(c, c->ip4.our_tap_addr, 67, dst, 68, &resp, dlen); > > > > return 1; > > } > > + > > Same here. > > -- > Stefano > --=20 Quique Llorente CNV networking Senior Software Engineer Red Hat EMEA ellorent@redhat.com @RedHat Red Hat Red Hat