From owner-svn-src-head@freebsd.org Sun Apr 19 14:23:33 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 98F572C75D2 for ; Sun, 19 Apr 2020 14:23:33 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 494sWS6VgSz4MSD for ; Sun, 19 Apr 2020 14:23:32 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x741.google.com with SMTP id s63so7784798qke.4 for ; Sun, 19 Apr 2020 07:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=luXC7RSSeAn2aa8YFbfds7Jtk+NVMT0NXCZVg4Vw/Q4=; b=jYIOOe8dvTDuD4B3IPaPxAt4zmwYP+CxZRuCDnEGVTLs/8XYNPyM8RL4NrnwYEcNTf spD+Et3HTOJVd9Fwc1WIiz71tBJ+8m2LEAmOkhrlRg+3fk7ft6VjYYMvfUoHIxjx925W Cwmz2nD7Uuyt+XTO0/0HSImDMw0iMyrS1jiTJ+bdc//fcvz8Zv4J9sk7CtlC5Es0j3wg Hhfgo7B66adzICpRPGJ8XEqv6bkUmghi2yicIxnC+BYhAzUgGC3t29VpjXKZJtDOs74e Zj4+/N8V7tpaVoFaGHTWnL/k/72duofZELi5+4uL8dJk3Vj8Gb5SOGTAr2kWGdBgbh+I zLJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=luXC7RSSeAn2aa8YFbfds7Jtk+NVMT0NXCZVg4Vw/Q4=; b=pUEc8W//dpcyBWwfY+keKncvQ6MbabGMkFPrOmbQ07bz+CYesCXxIUDr0VeqEj2pHg vhkFa+EobK3PQnOJED6YIqsRSZTABuFAJPxVjyI3278Hf7UwvP1vIlyyt8rjzs8xfUgN EjMUQbKkBVT+t0iLJ7NS4BtICCme/sVC4h6PY9EcCykuTayMQsWy80dMK7vbHthw7JIP cnZbB2eLgLXwqi72a7i1FXVxvFgX9R2O+OUKWt81UHedv2sJUEBlqp/h+2khCR1yrSUI Gi1b6EKUqbd6272NPHAF0S9RloJk3mmqHml4EdXrG4cHT6rv312JY2GxnSMmGA1nifGQ FGww== X-Gm-Message-State: AGi0PuayEmEFQePCRS90SH75vxfOlLKwXqAIQxW/630SwX5RoNk1UFo4 amzRJT3aXe1pFMvHNvrYQifnXg== X-Google-Smtp-Source: APiQypLVI81j2KuGn6I4EMQg1dzMgK/w6lyXs/grrkJPbr98Ob54uceYE2jDTFzYsW/NV+NsKJLGKg== X-Received: by 2002:a37:bec5:: with SMTP id o188mr11769255qkf.165.1587306211785; Sun, 19 Apr 2020 07:23:31 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-231-224.bltmmd.fios.verizon.net. [100.16.231.224]) by smtp.gmail.com with ESMTPSA id m83sm15618898qke.117.2020.04.19.07.23.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 07:23:31 -0700 (PDT) Date: Sun, 19 Apr 2020 10:23:27 -0400 From: Shawn Webb To: Kristof Provost Cc: Ronald Klop , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r360068 - in head/sys: kern net sys Message-ID: <20200419142327.nhotyboqubk3vl2l@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <202004180750.03I7oUK6032898@repo.freebsd.org> <67B55A62-848B-4876-8367-DE0D32A8B7D4@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="flj6q4ccadmcdqix" Content-Disposition: inline In-Reply-To: <67B55A62-848B-4876-8367-DE0D32A8B7D4@FreeBSD.org> X-Rspamd-Queue-Id: 494sWS6VgSz4MSD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=jYIOOe8d; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::741 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-4.26 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCVD_IN_DNSWL_NONE(0.00)[1.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-0.16)[ip: (0.01), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[224.231.16.100.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 14:23:33 -0000 --flj6q4ccadmcdqix Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 19, 2020 at 04:19:06PM +0200, Kristof Provost wrote: > On 19 Apr 2020, at 15:33, Ronald Klop wrote: > > On Sat, 18 Apr 2020 09:50:30 +0200, Kristof Provost > > wrote: > >=20 > > > Author: kp > > > Date: Sat Apr 18 07:50:30 2020 > > > New Revision: 360068 > > > URL: https://svnweb.freebsd.org/changeset/base/360068 > > >=20 > > > Log: > > > ethersubr: Make the mac address generation more robust > > > If we create two (vnet) jails and create a bridge interface in each > > > we end up > > > with the same mac address on both bridge interfaces. > > > These very often conflicts, resulting in same mac address in both > > > jails. > > > Mitigate this problem by including the jail name in the mac address. > > > Reviewed by: kevans, melifaro > > > MFC after: 1 week > > > Differential Revision: https://reviews.freebsd.org/D24383 > > >=20 > > > Modified: > > > head/sys/kern/kern_jail.c > > > head/sys/net/if_ethersubr.c > > > head/sys/sys/jail.h > > >=20 > > > Modified: head/sys/kern/kern_jail.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > --- head/sys/kern/kern_jail.c Sat Apr 18 03:14:16 2020 (r360067) > > > +++ head/sys/kern/kern_jail.c Sat Apr 18 07:50:30 2020 (r360068) > > > @@ -2920,6 +2920,15 @@ getcredhostid(struct ucred *cred, unsigned > > > long *hosti > > > mtx_unlock(&cred->cr_prison->pr_mtx); > > > } > > > +void > > > +getjailname(struct ucred *cred, char *name, size_t len) > > > +{ > > > + > > > + mtx_lock(&cred->cr_prison->pr_mtx); > > > + strlcpy(name, cred->cr_prison->pr_name, len); > > > + mtx_unlock(&cred->cr_prison->pr_mtx); > > > +} > > > + > > > #ifdef VIMAGE > > > /* > > > * Determine whether the prison represented by cred owns > > >=20 > > > Modified: head/sys/net/if_ethersubr.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > --- head/sys/net/if_ethersubr.c Sat Apr 18 03:14:16 2020 (r360067) > > > +++ head/sys/net/if_ethersubr.c Sat Apr 18 07:50:30 2020 (r360068) > > > @@ -1419,27 +1419,39 @@ ether_8021q_frame(struct mbuf **mp, struct > > > ifnet *ife, > > > /* > > > * Allocate an address from the FreeBSD Foundation OUI. This uses a > > > - * cryptographic hash function on the containing jail's UUID and > > > the interface > > > - * name to attempt to provide a unique but stable address. > > > Pseudo-interfaces > > > - * which require a MAC address should use this function to allocate > > > - * non-locally-administered addresses. > > > + * cryptographic hash function on the containing jail's name, UUID > > > and the > > > + * interface name to attempt to provide a unique but stable address. > > > + * Pseudo-interfaces which require a MAC address should use this > > > function to > > > + * allocate non-locally-administered addresses. > > > */ > > > void > > > ether_gen_addr(struct ifnet *ifp, struct ether_addr *hwaddr) > > > { > > > -#define ETHER_GEN_ADDR_BUFSIZ HOSTUUIDLEN + IFNAMSIZ + 2 > > > SHA1_CTX ctx; > > > - char buf[ETHER_GEN_ADDR_BUFSIZ]; > > > + char *buf; > > > char uuid[HOSTUUIDLEN + 1]; > > > uint64_t addr; > > > int i, sz; > > > char digest[SHA1_RESULTLEN]; > > > + char jailname[MAXHOSTNAMELEN]; > > > getcredhostuuid(curthread->td_ucred, uuid, sizeof(uuid)); > > > - sz =3D snprintf(buf, ETHER_GEN_ADDR_BUFSIZ, "%s-%s", uuid, > > > ifp->if_xname); > > > + /* If each (vnet) jail would also have a unique hostuuid this > > > would not > > > + * be necessary. */ > > > + getjailname(curthread->td_ucred, jailname, sizeof(jailname)); > > > + sz =3D asprintf(&buf, M_TEMP, "%s-%s-%s", uuid, if_name(ifp), > > > + jailname); > > > + if (sz < 0) { > > > + /* Fall back to a random mac address. */ > >=20 > >=20 > > I was wondering if it would be valuable to give this fall back something > > like: > >=20 > > printf("%s: unable to create fixed mac address; using random > > mac address", if_name(ifp)); > >=20 > > This will only be printed in rare circumstances. But in that case will > > provide valuable information. > >=20 > That would potentially be valuable, yes. On the other hand, we traditiona= lly > don???t sprinkle a lot of printf()s around in the kernel. This is extreme= ly > unlikely to happen, and if it does odds are attaching the interface will > fail at an earlier or later point, you may struggle to pass packets and r= un > into any number of other issues. > It???s also possible to diagnose absent the printf(), because the MAC > address will be locally administered rather than within the FreeBSD OUI. >=20 > So, in short: not a bad idea. You can argue it both ways, and I find myse= lf > (weakly) on the opposite side. Would displaying the message only when verbose boot mode is enabled be a suitable compromise? Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --flj6q4ccadmcdqix Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl6cXtgACgkQ/y5nonf4 4fpcDw//W2EWrllSHRy0LWiNhEeaRxQfkStXDJfsZN0YOkeTSn8fOdxeftFQSj7R geY35ZWdd6y56u5UFyP0lszRQMTPgwT5mvhKE4fDaY81rVdiP952KUBUBXmp8hVm ojIhdsFRbGjW6irDP3RfOcu/eZxiCfHGgmD0l/QeLsckP230y8jgl22agy5r/4U1 kG9L4o70E1bk+5qNrI3CfFL3FWarWBDGG+Hd4waV3Nv0WA6hPtLkltYgdOt6SUP3 d0Pi5KUOUrES70mrsIy5QO/oORLHr7SuuKKS9Hzd2wYygY99SaOgU9hR4fH6MpZu ruEY3HfspNkDv1tFPVg1hCO8U6yiDIpWgqpbh3czjUQGluFvWrvAu91WHE+/im4r ZUU7fh882zb3QWBEfOtwoH7wv2O8uWC5Eu45ynZfyctxyiAMa1bOn6Y53yHSvX4N dG4pQEfn5sA3gDn5i+MD4pO494WmULLxISgCdORAPL3+oPDMr0aCgVZ60EiIuUhs s89694ymqTiF3tPatY9rideN/j/6T+rBVIRScSpj4/Nm01oFfiZoFm91OW0VEDRM BupsHzIG0ICtnGvN/8InyVvbYLZGVRe7zyUp/Fx7919m9jjr16QmL7VP3nwDKWJx HyfOKUGohJwrtyPmv2i528Mv9kV9HSfDKguE0TBR+6p0WmRe5Gk= =6E5S -----END PGP SIGNATURE----- --flj6q4ccadmcdqix--