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  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

Powered by blists - more mailing lists