netdev - Re: [RFCv3 bluetooth-next 4/4] 6lowpan: iphc: add support for stateful compression

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 11 Dec 2015 20:49:23 +0100
From:	Alexander Aring <alex.aring@...il.com>
To:	Stefan Schmidt <stefan@....samsung.com>
Cc:	linux-wpan@...r.kernel.org, linux-bluetooth@...r.kernel.org,
	netdev@...r.kernel.org, kernel@...gutronix.de, mcr@...delman.ca,
	lukasz.duda@...dicsemi.no, martin.gergeleit@...rm.de
Subject: Re: [RFCv3 bluetooth-next 4/4] 6lowpan: iphc: add support for
 stateful compression

On Fri, Dec 11, 2015 at 08:11:42PM +0100, Stefan Schmidt wrote:
> Hello.
> 
> On 11/12/15 18:05, Alexander Aring wrote:
> >Hi,
> >
> >status update here.
> >
> >I implemented successful basic 6CO RA messages at sending and
> >processing inside radvd.
> >
> >There might also the question if processing 6CO inside kernel or
> >userspace? I put the basic functionality inside userspace for now.
> 
> How are you feeding the entries your receive back into the kernel? The
> debugfs interface right now?
> If we want to go with userspace handling for 6CO we need something better at
> some point.
> 

yes. For testing it's fine, I think we should add first support this way. If
we see it seems to be working well then making better UAPI interface.

I currently complete ignore the lifetime thing and handle it like
lifetime is non-zero.

For the lifetime handling, I think we need more than just a "bool", we
need flags. Because we need indicate "somehow" the "C flag" and if the
entry is "added" or "not added" (some active/enabled flag). See [0], or
we do that by check on "::" address/prefix, but I would not do that so far
nobody says that's an invalid prefix.

Then also the question is if doing the lifetime of a context inside the
kernel or in userspace (handled by $USERSPACE_PROGRAM, e.g. radvd). I think
radvd can handle this. See [1]:

The prefix information is timed out as specified in [RFC4861].  When
the Valid Lifetime for a context table entry expires, the entry is
placed in a receive-only mode, which is the equivalent of
receiving a 6CO for that context with C=0.  The entry is held in
receive-only mode for a period of twice the default Router Lifetime,
after which the entry is removed.

For this we need the "C" flag and "active" flag (indicate remove). That
the entry is held could be very simple by a timer in kernel, but
otherwise $USERSPACE_PROGRAM could also do this job by handle the
lifetime only in userspace, when lifetime expires -> manipulating the table.

I am not sure what's the best option here is.

BTW:

One bad news is, that radvd needs now to run under "root" with this
changes and it seems that it can running without root right before. This
might be getting a problem when trying to send such feature uptream to
radvd.

Testing:

I already test the new stateful compression patch (manipulating entries in
RIOT manually (no RA messages processing on RIOT).
It works fine under RIOT by manipulating RIOT's context table.

- Alex

[0] https://tools.ietf.org/html/rfc6775#section-5.4.2
[1] https://tools.ietf.org/html/rfc6775#section-5.4.3
--
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