netdev - Re: [PATCH net v3] net: ipv6: allow explicitly choosing optimistic addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAedzxoF2gJit1e05UJSOWX2RJwbA1PSbdABK3zgta-XtajJyw@mail.gmail.com>
Date:	Wed, 4 Feb 2015 19:38:11 +0900
From:	Erik Kline <ek@...gle.com>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>
Subject: Re: [PATCH net v3] net: ipv6: allow explicitly choosing optimistic addresses

>> +               bool optimistic_ok = (ifp->flags & IFA_F_OPTIMISTIC) &&
>> +                                    (banned_flags == IFA_F_TENTATIVE);
>
> Not sure if this can happen in any real use case, but I think that
> technically this is incorrect if banned_flags contains both
> IFA_F_TENTATIVE and other flags that aren't IFA_F_OPTIMISTIC. For
> example, suppose banned_flags = IFA_F_TENTATIVE | IFA_F_PERMANENT. In
> that case, I think the code would reject an address with
> IFA_F_TENTATIVE | IFA_F_OPTIMISTIC. You might be able to fix that

Exactly what I was trying to address, but I tried to choose the
uber-conservative option and require folks to explicitly list when
optimistic should be treated distinctly from tentative.

That of course, wasn't really future-proof and someone might not know
or simply forget to update this check as needed.

>                ifp_flags = ifp->flags;
>                if (ifp_flags & IFA_F_OPTIMISTIC) ifp_flags &= ~IFA_F_TENTATIVE;

I think this is cleaner.  I've got a version now that incorporates this.

One more thing I just noticed, though: if the interface and the
address matches the supplied arguments but we don't like the flags we
keep on processing all other addresses on that interface I think.  Is
that right?  (Easy to fix in a follow on patch.)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html