linux-kernel - Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.

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] [day] [month] [year] [list]

Message-ID: <aad376ad-ebe2-ec3a-15c9-187f63594083@collabora.com>
Date:   Mon, 22 May 2017 18:59:16 +0200
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Johannes Berg <johannes@...solutions.net>,
        Dan Williams <dcbw@...hat.com>,
        "David S . Miller" <davem@...emloft.net>,
        linux-wireless@...r.kernel.org
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Dmitry Shmidt <dimitrysh@...gle.com>,
        helmut.schaa@...glemail.com
Subject: Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.

Hi,

On 22/05/17 18:24, Johannes Berg wrote:
> 
>> Couldn't userspace just look at NL80211_BSS_SEEN_MS_AGO to filter and
>> create its own list?  Given that the kernel provides the information
>> userspace needs to figure out the age of a particular BSS, it doesn't
>> seem like there needs to be a kernel tunable for this.  Userspace can
>> already avoid stale results.
> 
> Yeah, I agree. It can also ask for a flush, so that old results are
> gone by the time the next scan returns. We don't have a flush operation
> without requesting a new scan, but I guess that could be added.
> 

Ok, guess I understand what you're saying. Thanks for pointing me in the right
direction.

>> Also, different runtime situations might want different result ages,
>> which wouldn't be possible if the kernel had a hardcoded maximum. 
>> Furthermore, different userspace apps might be reading the same scan
>> list, and they might have different ideas about staleness.
>>
>> Or perhaps I misunderstand the problem, which could well be the case.
> 
> No, I think this is perfectly right - userspace should be able to deal
> with this given the tools we gave it, or if not, we should probably
> just give it more tools instead of hardcoding the kernel configuration.
> 
> This value really just kinda needed to be an upper bound so that we
> don't start expiring entries while we're still scanning.
> 
> johannes
>