svn commit: r360068 - in head/sys: kern net sys
Shawn Webb
shawn.webb at hardenedbsd.org
Sun Apr 19 14:23:33 UTC 2020
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 <kp at freebsd.org>
> > wrote:
> >
> > > Author: kp
> > > Date: Sat Apr 18 07:50:30 2020
> > > New Revision: 360068
> > > URL: https://svnweb.freebsd.org/changeset/base/360068
> > >
> > > 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
> > >
> > > Modified:
> > > head/sys/kern/kern_jail.c
> > > head/sys/net/if_ethersubr.c
> > > head/sys/sys/jail.h
> > >
> > > Modified: head/sys/kern/kern_jail.c
> > > ==============================================================================
> > > --- 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
> > >
> > > Modified: head/sys/net/if_ethersubr.c
> > > ==============================================================================
> > > --- 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 = 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 = asprintf(&buf, M_TEMP, "%s-%s-%s", uuid, if_name(ifp),
> > > + jailname);
> > > + if (sz < 0) {
> > > + /* Fall back to a random mac address. */
> >
> >
> > I was wondering if it would be valuable to give this fall back something
> > like:
> >
> > printf("%s: unable to create fixed mac address; using random
> > mac address", if_name(ifp));
> >
> > This will only be printed in rare circumstances. But in that case will
> > provide valuable information.
> >
> That would potentially be valuable, yes. On the other hand, we traditionally
> don???t sprinkle a lot of printf()s around in the kernel. This is extremely
> 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 run
> 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.
>
> So, in short: not a bad idea. You can argue it both ways, and I find myself
> (weakly) on the opposite side.
Would displaying the message only when verbose boot mode is enabled be
a suitable compromise?
Thanks,
--
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/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20200419/e09781cf/attachment.sig>
More information about the svn-src-head
mailing list