[PATCH] glibc: Terminate process on invalid netlink response from kernel [BZ #12926]
Florian Weimer
fweimer@redhat.com
Mon Nov 9 11:50:00 GMT 2015
On 11/05/2015 03:36 PM, Hannes Frederic Sowa wrote:
>> The more fundamental question is whether we actually have to copy all
>> the addresses to userspace. In the end, it may be better to hand a list
>> of destination addresses to the kernel and have it sort them according
>> to some algorithm. But for the algorithm proposed in RFC 6724 section
>> 6, this may be not worth the effort because there are so many
>> configurable bits.
>
> I would rather not provide a holistic sort function in the kernel for
> both IPv4 and IPv6 which would a requirement by glibc, no?
That depends on what we are trying to solve, and what the desired
semantics. RFC 6724 probably does not real -world requirements or what
any system does, unfortunately. Our situation is also different from
other designs because glibc has at most a single-process view, and for
dead address detection, you'd want a whole-system view (or at least
whole-user view, to avoid local information disclosure).
If we get rid of longest prefix matching, I am not sure how much sorting
actually needs kernel assistance. We still need to know if there is
IPv4 or IPv6 support, but maybe it's better to perform a routing table
lookup and drop addresses which are known to be unreachable from a host
perspective.
>> I still think most of the address sorting is bogus because it appears to
>> make guarantees which can break after renumbering.
>
> Yes, of course.
>
> Your patch for glibc looks fine to me, so
>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks, I have committed this now. I hope this is okay—you have
reviewed the kernel aspect, and Mike looked at things from a glibc
perspective.
Florian
More information about the Libc-alpha
mailing list