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

Message-ID: <1495470254.26008.3.camel@sipsolutions.net>
Date:   Mon, 22 May 2017 18:24:14 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Dan Williams <dcbw@...hat.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.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.

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

> 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