netdev - Re: [RFC] [GIT PATCH net-2.6.23] IPV6: Configurable IPv6 address selection policy table (RFC3484)

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]

Date:	Sat, 28 Apr 2007 23:17:07 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	yoshfuji@...ux-ipv6.org
Cc:	drepper@...hat.com, netdev@...r.kernel.org
Subject: Re: [RFC] [GIT PATCH net-2.6.23] IPV6: Configurable IPv6 address
 selection policy table (RFC3484)

From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@...ux-ipv6.org>
Date: Thu, 19 Apr 2007 16:28:56 +0900 (JST)

> We store labels only in kernel, and leave precedence in userspace
> (/etc/gai.conf), so far.  The name resolution library (getaddrinfo(3))
> is required to be changed to try reading label information from kernel.
> On the other hand, on BSDs or on Solaris, full policy table including
> precedence seems to be stored in kernel, and the name resolution
> libary (getaddrinfo(3)) seems to use that information.
> We could choose this approach.
> 
> Note: Solaris uses string (up to 15 characters excluding NUL) labels.

As you mention the main problem is efficiently notifying
userspace that the table has changed in the same way that
file changes can be checked.

The last thing we want is for glibc to have to stat a bunch of files
every time it wants to do something, it does enough of that already
:-)

Probably, to start somewhere, it may be wise to put the entire
precedence table in the kernel just like BSD, Solaris, and your
patch do.  We can figure out how to make the update interface
efficient later, perhaps with something clever in netlink.

One idea is to have glibc have some kind of socket open, subscribed
to a group which gets "sticky" events.  It will be simple messages
such as "table of type X got updated".  If the socket already got
sent that message, on subsequent updates we wouldn't send it again
until glibc read the event message out.

It would be possible to not even use explicit messages.  Instead
some netlink socket state holds a generation counter, label
table updates increment the counter, and glibc just asks the
kernel via netlink whether it's generation count is out of date.
If so, the kernel returns true and also updates the generation
count for that socket to match the current one.

It is one idea.

-
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